Cream of the Crop 26

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 26 / Cream of the Crop 26.iso / os2 / lxlt121.zip / lxLite / doc / lxLite.INF (.txt) < prev next >

Wrap

OS/2 Help File | 1997-08-17 | 143KB | 2,843 lines

ΓòÉΓòÉΓòÉ 1. lxLite User's Guide ΓòÉΓòÉΓòÉ Dedicated to my little daughter Alice, born 12 Feb, 1996 at 03:45. Distribution Starting from version 1.1.9 I at last decided (really I at last realized what it really is :-) ) to distribute lxLite under GNU General Public License (GPL). The program is written exclusively using Virtual Pascal, with use of its built-in 32-bit assembler. This is an excellent language which takes full advantages of OS/2`s possibilities, is BorlandPascal compatible, and have a much more powerful than BP built-in optimizer. Contents Introduction Features Command-line switches Configuration file Error messages Known bugs and limitations Thanks... lxLite Utility Pack Author info You really should read the "what's new" section which contains many things I was too lazy to add to documentation. Also is available a German version of documentation (although in plain .TXT format, and a little out of date - for version 1.1.5). Also available a short overview in Russian (codepage 866). ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓòÉΓòÉΓòÉ 1.1. Author info ΓòÉΓòÉΓòÉ Andrew Pavel Zabolotny Born Jan, 25, 1973 in Kishinev, Moldova, I moved around `95 to St. Petersburg, Russia. I'm currently working as system programmer at the Information Security Center of I.M.I.C.S. (Institute of Modelling and Intellectualization of Complex Systems) at the St. Petersburg's State Electrotechnical University. All my spare time I`m dedicating to my family (esp. to my 1-year-old daughter Alice) and to system programming. Most (alas) of my programs I wrote for Mess-DOS, but last two years I`m trying to make familiar with the Architecture Of Real Operating Systems {tm} :-), particularily that of OS/2, and (sometimes :-) I`m writing Small But Very Useful Utilites :-) Perhaps, the most useful of them is lxLite - an OS/2 executables compressor, something like LZEXE, PKLITE etc in the world of DOS. You can find it (perhaps) on the hobbes.nmsu.edu archive in the /os2/archive subdirectory (although I do not agree with classifying lxLite as an archiver :-), it is rather a mixture of a system tool with a programming tool (since it allows to do a lot of with the structure of LX executable modules ) ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ To contact me, please write to bit@freya.etu.ru or you can return to title page ΓòÉΓòÉΓòÉ 1.2. GNU General Public License ΓòÉΓòÉΓòÉ GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 675 Mass Ave, Cambridge, MA 02139, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS Appendix: How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) 19yy This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) 19yy name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. <signature of Ty Coon>, 1 April 1989 Ty Coon, President of Vice This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. ΓòÉΓòÉΓòÉ 1.3. Known bugs and limitations ΓòÉΓòÉΓòÉ Known bugs and limitations Here are a list of executables which failed for some reasons to work packed; avoid packing them (lxLite will do it automatically, but if you renamed them lxLite will not recognize them). PMJPEG v1.5. However, even IBM`s REPACK cannot repack it, so I think this is because of either a bug in a linker used to generate it (and its executable has a strange structure) or a kind of debug protection (executable checksum checking?) VX-REXX executables. The main body of such executables (REXX ciphered code) is simply appended to a small LX stub. Such executables have an unknown structure and after lxLite packs its stub they become completely obsolete. Watcom C & C++ v>=10.0. Seems that Watcom likes to append garbage to LX files. These executables are meant for running in both OS/2 and DOS sessions and also have a strange structure. ; InterCom since it is protected from any kind of tampering. \OS2BOOT. OS2LDR expects OS2BOOT to be in NE format. ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Title page | Introduction | Features | Command-line switches | Configuration file | Error messages | Thanks... | Utility Pack | Author info ΓòÉΓòÉΓòÉ 1.4. Configuration file ΓòÉΓòÉΓòÉ Configuration file The .CFG file format is as simple as possible: it is a plain ASCII text file which you can edit using any editor which supports them (almost any). Any characters after a semicolumn ';' are ignored, i.e. you can put comments in configuration file like this: ; This is an comment You can define sections using widely used unix-configuration-file style, i.e. [section 1] section 1 content [section 2] section 2 content ... The word in square brackets is used to identify the configuration. This is an example of a configuration entry: [newStub] /ANP:0 /F+ /YDL /YXL /MRN /MLN /U- As you can see, inside the section you should put any switches just like you do on the command line. Recursive /C options are NOT ignored, so you can link one configuration to another. Note, however, that lxLite will refuse to load same configuration twice to avoid infinite-loop recursion, i.e. "lxLite /c:One /c:Two /c:One" will load `One` configuration only ONCE. Every section can have multiple names, for example: [newStub ReplaceStub SetNewStub] /ANP:0 /F+ /YDL /YXL /MRN /MLN /U- This section is identified by three identifiers, i.e. /c:newstub, /c:replacestub and /c:setnewstub switches will have same effect. If section identifier begins with a / (slash) character, it is treated as a special case: the text following the slash is treated as a list of file masks on which this section will be applied automatically. For example, if we want to remove stubs automatically on all .DLL files, we have to write a configuration section like: [/*.dll] /t /zs ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Title page | Introduction | Features | Command-line switches | Error messages | Bugs and limitations | Thanks... | Utility Pack | Author info ΓòÉΓòÉΓòÉ 1.5. lxLite_de.txt ΓòÉΓòÉΓòÉ ---------------------------------------------------- lxLite - ein Packer fuer ausfuehrbare OS/2-Dateien ---------------------------------------------------- Widmung: Meiner kleinen Tochter Alice, geboren am 12 Feb, 1996 um 03:45. 0. Version der deutschen Dokumentation -------------------------------------- Die deutsche Uebersetzung basiert auf der englischen Dokumentation zu lxLite 1.1.5. 1. Distribution --------------- Dieses Programm ist Freeware. Das heisst, man kann es verbreiten, wie man will, ausser fuer den kommerziellen Gebrauch. Kommerzielle Verwendung ist nur mit meiner ausdruecklichen Zustimmung erlaubt. Wie man mich kontaktieren kann ist in der letzten Sektion dieser Datei zu sehen. Freeware heisst aber auch, dass es keinerlei Garantie fuer das gibt, was das Programm macht, ob es das macht was man erwartet, ob es ueberhaupt etwas macht. Ich uebernehme keinerlei Verantwortung fuer irgendeinen Schaden, entgangene Profite etc., die durch Fehler dieses Programms (oder der Uebersetzung der Dokumentation) verursacht werden. Wie auch immer, es ist erlaubt, das Programm dazu zu verwenden, um jedes, auch jedes kommerzielle Produkt zu verbessern. Und zwar nicht um den eigenen Vorteil, sondern um den Vorteil aller armen User, die sich mit riesigen Programmdateien herumaergern muessen. Das Programm ist ausschliesslich in Virtual Pascal 1.0 Beta #003, geschrieben, vor allem mit dem eingebauten 32-bit Assembler. Virtual Pascal ist eine excellente Sprache, die alle Vorteile und Moeglichkeiten von OS/2 bedient und unterstuetzt, gleichzeitig Borland Pascal kompatibel ist, und einen maechtigen eingebauten Optimierer hat. Falls du den Source Code von lxLite willst, bitte wende Dich an mich, aber du musst mir ganz sagen WARUM du ihn brauchst; Leute, die fremde Programme unter eigenem Namen verkaufen wollen, bekommen ihn sicher nicht. 2. Einfuehrung ------------- Ich denke, wir alle sind recht sauer ueber die gewaltige Groesse die fast alle modernen Programme haben, die unter OS/2 laufen (fuer WinDOS gilt allerdings das gleiche), ohne oft entscheidend mehr zu koennen als Programme frueherer Zeiten. Ich verstehe nicht, warum sie so gross sind, weil die meisten Compiler, sogar IBM CSet generieren Code in moderaten Groessen. Nehmen wir als Beispiel das allseits bekannte MultiMaint. Was um alles in der Welt macht das Ding in einer 700K grossen EXE-Datei? Ich verstehe es nicht. Dazu kommt noch, warum wird die beinahe gleiche EXE-Datei noch doppelt und dreifach dazugepackt (Ich meine MultiSafe und IniMaint, die mit MultiMaint daherkommen). Das Programm ist ja ganz nett und es macht seine Arbeit ganz gut, aber fuer diese Arbeit ist es einfach zu gross. OS/2 Kernel haben etwa den gleichen Umfang. Wo ist da die Relation? Ich kann (und will) es mir einfach nicht leisten so einen grossen Haufen Mist auf meine Platte zu laden, also habe ich MultiMaint & Co. wieder gekuebelt. Zu Dumm fuer deren Autoren. lxLite ist ein Workaround fuer dieses Problem. Programmdateien kann man packen, sie nehmen dann nur noch den halben Platz ein, und machen noch immer den glichen Job. Dummerweise braucht es auch den gleichen Platz im Speicher - das ist die Schuld des Autors. Soviel ich weiss, gibt es fuer OS/2 nur ein Programm, das etwas Aehnliches macht REPACK von IBM (EWS?). Aber vergleichen mit lxLite erzeugt es groessere Dateien, obwohl es den gleichen Algorithmus verwendet. Zum Beispiel, COURIER.FON aus OS/2 Warp Build 8.192 wird von REPACK zu 44K, von lxLite aber in 34K gepackt. Spuer den Unterschied! BTW, LINK386+Ressource Compiler compilieren COURIER.FON auch in ein 44K-Datei. Daher denke ich, dass das sie eine gemeinsame Library verwenden. Ich komprimierte alle meine Programmdateien (inklusive aber nicht nur ?:\os2\*.exe, ?:\os2\dll\*.* und ?:\os2\dll\ibmnull;laserjet) und mein System ist nach wie vor stabil. Ein lxLite Benutzer (Pavel Roskin) hat festgestellt, dass lxLite sogar os2krnl komprimiert:-) Sehr angenehm vor allem fuer eine einzelne Bootdiskette [Anmerkung d. Uebersetzers: Es stimmt]. 3. Features ----------- lxLite komprimiert die Dateien auf die gleiche Art wie LINK386 es tut. Es gibt keine andere Moeglichkeit gepackte Programmdateien unter OS/2 zu implementieren, als die zwei, die OS/2 Warp (oder die eine die 2.x) kennt. So, hier ist eine kurze Beschreibung dieser beiden Algorithmen: 1. Run-length packing. Das ist im Prinzip die gleiche Methode, wie sie Microsoft C fuer DOS verwendet. Das Ergebnis ist sehr SCHLECHT, weils sich Programmdateien nicht fuer die Pack-Methode eignen. Zum Beispiel, PCX Dateien werden auf die gleiche Art gepackt. 2. Eine Art Lempel-Ziv Algorithmus. Lempel-Ziv ist die Methode, die beinahe alle DOS-EXE Packer verwenden - LZEXE, PKLITE, PGMPAK etc. Die Methode die fuer ausfuehrebare OS/2 Dateien standardisiert ist, ist IMHO nicht die effektivste. Dazu kommt noch, dass OS/2-Programmdateien einen anderen Ladealgorithmus haben als DOS-EXE-Dateien, Teile von OS/2-Programmdateien koennen auch nur geladen werden, wenn sie gebraucht werden. Deshalb kann ein Lempel-Ziv Woerterbuch nicht ueber eine einzelne Page (4096 Bytes) hinausgehen. Folglich sind die Resultate auch nicht so gut, wie sie theoretisch sein koennten. lxLite kann beide Methoden verwenden, sowohl zum Packen, als auch zum Entpacken. Im Allgemeinen ergibt die zweite Methode die besseren Resultate, aber moeglicherweise (?) gibt es Dateien fuer die die erste besser ist. Aus diesem Grund werden defaultmaessig beide Methoden angewendet, die mit dem kleineren Ergebnis gewaehlt. lxLite kann auch benutzt werden, um Dateien zu entpacken, die bereits komprimiert sind, sei es mit mit lxLite, LINK386 oder REPACK von IBM. Was fuer Dateien koennen nun mit lxLite gepackt werden? Das LX Format wird unter OS/2 beinahe ueberall verwendet: Beinahe alles ist im LX format. Nicht nur EXE-Dateien, sondern auch .DLL, .PDR, .QPR, .DRV, .FON, .SYS-Dateien koennen mit lxLite gepackt werden. Sogar die VDDs (Virtual Device Drivers) in \OS2\MDOS koennen damit gepackt werden. Praktisch kann man lxLite auf jedes Datei loslassen: Wenn es kein LX ist, wird lxLite es nicht anruehren. Es ist also moeglich, den ganzen \OS2\*\ zu komprimieren, man bekommt jede Menge Extraplatz ohne irgendwelchen Overhead! Die Dekompressionszeit wird durch die verkuerzten Ladezeiten der verkleinerten Dateien von der Platte bei weitem aufgewogen. Also, Reboot von einer Diskette (eventuell von den beiden Installationsdisketten und dann F3 waehlen, dann das entsprechende Laufwerk waehlen, wo das installierte OS/2 liegt. Dann ist folgendes beim Command prompt einzugeben: \[path]\lxLite os2\*.exe os2\dll\*.* os2\dll\ibmnull\*.drv und so weiter. So koennen auch die Dateien, welche zur Laufzeit normalerweise gesperrt (EXE,DLL) sind, problemlos gepackt werden. lxLite Version 1.00 und hoeher ist sogar in der Lage Dateien, die gerade benutzt werden, zu packen. In diesem Fall kann warnt lxLite und fragt nach ob es das Modul auslassen oder durch seine gepackte Version ersetzen soll. Grundsaetzlich ist das ersetzen auch so kein Problem, nur muss man im Hinterkopf behalten, dass das Original bereits im Speicher sitzt, und so auch jede Menge Platz im SWAPPER.DAT auffressen. Ein Reboot sobald wie moeglich ist daher immer eine gute Idee. Versionen von lxLite ueber 1.00 gibt es in zwei verschiedenen EXE-Dateien: lxLite.exe ist die normale Version fuer OS/2 v2.99, Warp und hoeher. Die andere, namens lxLite2x.exe ist fuer die aelteren 32 bit Versionen von OS/2 (i.e. 2.x, NICHT 1.x weil unter 1.x gab es das LX Format noch nicht). Als OS/2 Warp User kann man es getrost loeschen. Version 1.1.0 und Hoeher erkennen Programme, die Daten nach der eigent- lichen LX-Struktur stehen (i.e. was auf DOS overlay data heisst). Watcom`s gebundene Programme (wie WCC.EXE Versionen >= 10.0) und Watcom Visual Rexx Programme haben so eine Struktur. In diesem Fall erzeugt lxLite eine Warnung und ersucht um Bestaetigung, ob ein solches Programm wirklich gepackt werden soll. Es ist SEHR empfehlenswert, dass zuerst eine Kopie von diesem Programm gemacht wird, bevor man es zu packen versucht, denn die Chance, dass es danach nicht mehr geht, ist sehr hoch. Das deshalb, weil lxLite (natuerlich) keine (prinzipiell moeglichen) Pointer innerhalb des Programms, die auf Daten, die an das Programm gebunden sind (wie zum Beispiel VX-REXX Programme), veraendert. 4. Optionen ----------- Es gibt jede Menge Optionen in lxLite. Ich liebe Optionen einfach :-) Deshalb kann man bei lxLite beinahe alles und jedes konfigurieren. Um den User vor allzuviel Konfiguration zu schuetzen, unterstuetzt lxLite eine einzelne Konfigurationsdatei, in der gleich einige Konfigurationen mitgeliefert ('factory defaults') sind. Sie sind weiter unten aufgelistet: --------------------------------------------------------------------------- DEFAULT (wird standardmaessig geladen): DEFAULT ist eine `Arbeitskonfigura- tion'. Alle Parameter sind auf maximale Kompression gesetzt. Die Er- zeugung von .BAK Dateien ist abgeschaltet. Beachte, dass diese Konfiguration IMMER geladen wird, bevor irgendwelche andere Optionen wirksam werden, sogar die /C{#} Option wird ausgefuehrt NACHDEM die DEFAULT- Konfiguration geladen Worten ist. FAST: Niedrigste Kompressionsrate, kuerzeste Ladezeiten. Wenn man IBM glaubt, werden Programmdateien schneller geladen, wenn Datenobjekte innerhalb der Datei an Sektorgrenzen (512 Bytes) ausgerichtet werden. Ich kann eigentlich keinen Unterschied feststellen, daher: Selber ausprobieren! Vorkomprimierte Daten werden nicht de-komprimiert und wieder re-komprimiert. FAST2: Packt ein bisschen besser, aber langsamer. Ladezeiten sind so schnell wie bei CFG#1. VER2X: Optimal fuer pre-Warp Versionen von OS/2. Versionen vor Warp (3.0) wissen nichts von der Lempel-Ziv (/EXEPACK:2) Methode. Programme sollten nicht mit Lempel-Ziv gepackt werden, falls die Moeglichkeit besteht, dass sie unter OS/2 2.xx (ausser 2.99) laufen sollen. FAILSAFE: Lempel-Ziv packen ist eingeschaltet. Ein fehlersichere Konfigura- tion. Alle Daten werden genau wie von LINK386 geschrieben, deshalb sind die Dateien etwas groesser als bei der DEFAULT-Konfiguration. Nur fuer WARP (oder hoeher) und 2.99! MAX: Beste Kompressionsrate. SEHR LANGSAM! Wird wohl selten gebraucht wer- den. NEWSTUB: Das ist eine spezielle Konfiguration mit der man den DOS-Stub in LX Programmen durch einen anderen ersetzen kann, ohne irgendetwas anderen zu veraendern. Du musst einen Dateinamen fuer den neuen Stub angeben - diese Konfiguration teilt lxLite mit, dass es alte, gepackte Objekte nicht entpackt und unkomprimierte Objekte nicht packt. MINSTUB: Diese Konfiguration ist mit NEWSTUB verbunden und ersetzt durch den kleinstmoeglichen Stub vom Typ `say-error-and-exit`. Kleiner gehts nimmer (glaub ich zumindest), ausser du kuerzt die Fehlermeldung. VDMSTUB: Diese Konfiguration befiehlt lxLite, den vorgefundenen Stub durch einen`run-from-VDM`-Type zu ersetzen. Dieser ist auch so kurz, wie moeglich:-). Bitte die Beschreibung der /T{#} Option fuer weitere Details durchlesen. INFO: Diese Konfiguration verwenden, um an Informationen ueber die Programmdatei zu erhalten ohne es neu zu schreiben (siehe auch Option /V+) --------------------------------------------------------------------------- Um eine spezifische Konfiguration zu verwenden, ist lxLite mit /C# als Parameter aufzurufen, wobei # der Name der Konfiguration ist. Die Einstel- lungen sind in der Datei lxLite.CFG im gleichen Verzeichnis, in dem sich lxLite.EXE befindet. Kuemmere dich nicht um Pfade, lxLite wird sein .CFG schon finden. Beispiel: Um die Konfiguration `max` zu verwenden, starte lxLite /cMax. Fuer eine detailierte Beschreibung des .CFG-Dateiformats, lies die ueber- naechste Sektion. Nun kommt eine detaillierte Erklaerung darueber was jeder einzelne Switch tut. Jeder Switch, der das '+'- oder '-'-Zeichen akzeptiert (um Aktion ein- oder auszuschalten) kann auch ohne Zeichen benutzt werden, das heisst dann halt '+'. Das heisst z.B., /V+ ist gleich wie /V. /A{P|S|N{P|S}} setzt die Ausrichtungsmethode (Alignment) fuer das erste und die weiteren Objekte. Das erste Objekt kann man auf [P]age shift, [S]ector oder [N]o boundary ausrichten. Die letzte Option (No boundary) wird von LINK386 niemals benutzt, aber es funktioniert, und das LX Format erlaubt es. Alle Objekte ausser dem ersten MUeSSEN zumindest auf PageShift boundary ausgerichtet sein. PageShift ist ein Wert, der im LX Header spezifiziert ist. Um ihn neu zu definieren, verwende die /R# Option. /B{+|-} Das Umbenennen der Originaldatei in .BAK ein- (+) oder ausschalten (-). Beachte bitte, dass das eine BETA-Version ist - deshalb sind .BAK Dateien standardmaessig eingeschaltet. /C{#} Verwenden der Konfiguration mit ID = #. Die zwei vordefinierten Konfigurationsnamen sind "DEFAULT" und "UNPACK". Die Erste wird immer geladen, wenn lxLite startet und die Zweite wird benutzt wenn die /X+ Option angegeben wird (NICHT gleichbedeutend mit /cUnpack). /D{#} Ausschliessen[D]e Dateimaske. Alle Dateien die zu einer der angegebenen Dateimasken passen, werden von lxLite uebergangen. Alle Dateimasken muessen durch Doppelpunkte (:) voneinander getrennt sein (weil ein : nicht Teil einer Maske sein kann). Zum Beispiel wird /D*.zip:*.arj:*.rar lxLite daran hindern .zip, .arj and .rar Dateien zu bearbeiten. Standardmaessig (/Cdefault) enthaelt eine Liste aller Progreammdateien, von denen bekannt ist, dass sie nicht richtig gepackt werden koennen. Mehrere /D-Switches hintereinander werden addiert, daher ist /D*.zip /D*.arj /D*.rar das gleiche wie das obige Beispiel. Um die Liste zu loeschen ist einfach /D zu verwenden. /F{+|-} Erzwungenes repacking. Ist zu verwenden um die Meldung `already processed` zu uebergehen, i.e. wenn lxLite denkt, dass die Datei schon bearbeitet wurde, das aber in Wirklichkeit nicht der Fall war. Das passiert normalerweise nicht, kann aber passieren, wenn man versucht einen Stub durch einen anderen Stub derselben Groesse zu ersetzen, und zwar bei einer bereits komprimierten Datei. /G[X|D|S]{#} e[X]tra / [D]ebug / [S]tub Daten werden in die spezifizierte Datei [G]eschrieben. Wenn lxLite eine LX Datei findet, die solche Daten enthaelt, und man diese Daten verwerfen (oder ersetzen bei einem Stub) will, wird lxLite sie in die spezifizierte Datei stellen, bevor sie verworfen werden. Die {#} Komponente kann auch eine Dateimaske sein, sodass man Daten in Dateien mit demseleben Namen, aber einem anderen Extender schreiben kann. Zum Beispiel /GD*.dbg teilt lxLite mit, dass es zu verwerfende Debug-Informationen in Dateien mit demselben Namen aber der Endung ".dbg" schreiben soll; der switch /GS*.stub.$s$ auf die Datei "myfile.exe" schreibt den Stub in die Datei "myfile.stub.$s$". Siehe auch die /O Option. /I{+|-} Zwingt (+) lxLite dazu, mit Idle Prioritaet zu laufen. Das heisst, es arbeitet nur, wenn keine andere Aktivitaet im System herrscht (d.h. es wartet auf Tasten und Mausbewegungen). Das ist meiner Meinung nach am besten, da lxLite so im Hintergrund laufen kann und die Performance beinahe ueberhaupt nicht beeinflusst. Nur wenn man eine ungezogene DOS-Box laufen hat, die sich alle CPU-Zeit schnappt, bleibt lxLite stehen. Wenn lxLite nun mit /I- gestartet wird aendert es seine Prioritaet nicht auf Idle, und daher mit einer bestimmten Prioritaet (z.B. via PRIORITY.EXE) gestartet werden. /L{#} Instruirt lxLite ein Logfile anzulegen. Es enthaelt nur die Dateien, die lxLite auch bearbeitet, uebergangene Dateien werden hier nicht aufgenom- men. wenn kein Name angegeben ist, wird lxLite.log im Verzeichnis in dem sich auch lxLite.exe befindet verwendet. Neben dem Dateinamen wird die Anfangs- und Endgroesse und die Probleme (falls welche auftraten). /M{R{N|1|2|3}|L{N|1}} Setzt die Kompressionsmethode und -parameter. Das zweite Zeichen definiert die Methode, die verwendet werden soll: `R` steht fuer Run-Length (/EXEPACK:1) und 'L' fuer Lempel-Ziv (/EXEPACK:2). Das dritte Zeichen ist der Kompressionslevel, der mit der Methode erreicht werden soll; Falls N spezifiziert wird, ist die Methode abgeschaltet. Drei Levels gibt es fuer die Run-Length-Kompression. Der Level 1 ist der schnellste. Er sucht nur nach 1-Zeichen Strings. Zum Beispiel, ein 'AAAAAAAA' String wird erkannt und zu 8, 1, 'A' gespeichert, waehrend ein 'ABABABAB' String unkomprimiert gespeichert wird. Level 2 erkennt Strings jeder Laenge bis 16 Zeichen. Das Beispiel von oben wird zu 4,2,'AB' kodiert. Das ist die Standardeinstellung fuer die meisten 'Factory`-Konfigurationen. Und als letztes, der dritte Level sucht nach allen Strings jeder Laenge bis zu einen halben Page-Laenge (= 2048). Diese Kompressionsmethode ist SEHR langsam und ergibt selten echte Ergebnisse, man sollte sie nur verwenden wenn man sie wirklich braucht. Der Lempel-Ziv Algorithmus kann nur entweder abgeschaltet (/MLN) oder eingeschaltet (/ML1) sein. Wenn er eingeschaltet ist, sucht er nach al- len Matches unter Verwendung einer ziemlich schnellen Hash-Tabelle, des- halb gibts keinen Grund die Kompression abzustufen. /O{X|D|S}{+|-}. [O]utput e[X]tra/[D]ebug/[S]tub Daten immer (+) oder nur wenn verworfen (-). Wenn es abgeschaltet ist (/O-, Standard) arbeitet der /G Switch wie vorher, i.e. Daten werden nur geschrieben, wenn sie in der Quellda- tei verworfen werden sollen. Wenn die /O+ Option benutzt wird, werden die Daten immer geschrieben (wenn die entsprechende Dateimaske in /G Option angegeben wurde). Falls {X|D|S} nicht angegeben wird, gilt die Option fuer allen Arten von Daten (Extra,Debug,Stub) (i.e. /O+ schaltet das Feature fuer alle X/D/S Daten ein, /O- schaltet es fuer alle ab). /P{+|-} Ein- (+) oder ausschalten (-) einer Pause vor jeder Datei. Das Programm zeigt den Namen der Datei, die als naechstes gepackt werden soll, und ermoeglich eine Auswahl, ob sie bearbeitet oder in Ruhe gelassen werden soll. /Q Alle Konfigrationsoptionen abfragen. Im Prinzip ist das ein buntes Listing der lxLite.cfg Datei :-) Andere Optionen falls vorhanden, werden ignoriert. /R{#} [R]e-align (ausrichten) der Pages auf eine spezielle Boundary. (#) muss eine Potenz von 2 sein. Diese Option ist analog zu LINK386`s /ALIGN: Switch. Viele Programmierer kuemmern sich nicht darum, dass das /A: standardmaessig auf eine Boundary von 512 (ein Sektor) gesetzt ist und richten jede Page der ausfuehrbaren Module auf 512 Byte aus. Das Ergebnis ist ein Haufen unbenutzter Platz innerhalb der Programmdatei. Man kann nun solche Dateien mit einer anderen /ALIGN: Option neu linken. Standardmaessig ist /R:4. Um lxLite zu zwingen sich wie LINK386, muss man /R:512 verwenden. Das ist equivalent zu /ASS :-) . /S{+|-} Zeigen (+) oder nicht zeigen (-) der aktuellen Konfiguration. Das ist ganz brauchbar, um mal zu schauen welche Einstellungen in der CFG-Datei gespeichert sind, besonders bei verketteten Konfigurationen (siehe weiter unten). Beispiel: lxLite /CDEFAULT /S zeigt die standardmaessigen Einstellungen. /T{#} Die mit # spezifizierte Datei als neuen DOS-Stub verwenden. Ein DOS-Stub ist eine kleine DOS-.EXE-Datei, die in eine OS/2`s LX-Datei gelinked wird, damit das Programm eine Fehlermeldung ausgibt, wenn es von DOS aus gestartet wird. Normalerweise sieht das etwa folgend aus: Dieses Programm laeuft nur unter OS/2 Mit lxLite kommen 2 DOS-Stub-Programme mit: stub_min.bin und stub_vdm.bin. Der erste ist ein Standard-`Schreib geht nicht und Ende` Typ, aber er ist etwas kleiner als die ueblichen DOS-Stub-Programme die von den ueblichen Linkern erzeugt werden. Der zweite ist ein Stub, der eine neue OS/2-Session startet und das Programm daraus startet. Falls OS/2 nicht gefunden wird, die uebliche Fehlermeldung produziert. Standardmaessig laesst stub_vdm.bin OS/2 den Sitzungstyp bestimmen. Alternativ dazuy, kann man den Sitzungstyp auch in stub_vdm.bin festlegen. Dafuer braucht man einen Hexeditor - man muss nach dem String `SesType->' im Stub suchen und das Byte, das unmittelbar nach dem Pfeil kommt (->) durch den gewuenschten Sitzungstype ersetzen, wobei folgende Tabelle gilt: 00 - OS/2 session manager determines type (default) 01 - OS/2 full-screen session 02 - OS/2 windowed session 03 - PM application 04 - VDM full-screen session 07 - VDM windowed session /U{+|-} Ein- (+) oder ausschalten (-) des Entpackens einer Datei vor dem Packen. lxLite weiss wie man beide der beschriebenen Methoden zum Entpacken verwendet, deshalb ist die Option standardmaessig ist eingeschaltet. Ausschalten ist nur dann sinnvoll, wenn Zeit gespart werden soll. /V{+|-} Verbose (zeigt ein ganzen Haufen Dateiinformationen) Das ist der Schalter fuer Neugierige:-) Mit /V+ zeigt lxLite ein paar Informationen ueber die bearbeitete Datei an (um komplette Information ueber .LX Dateien zu bekommen, rate ich jedem exeHdr.EXE aus dem OS/2 Programmer`s Toolkit zu verwenden). /W{+|-} Ein- (+) oder ausschalten (-) ob das Ergebnis des Packens auf die Platte geschrieben werden soll. Standardmaessig ist es eingeschaltet (nona!), aber du kannst es ausschalten falls du die Informationen ueber /V+ anschauen willst, ohne die Datei neu zu packen und frisch zu schreiben. Diese Option kann auch fuer debugging der Optionen nuetzlich sein. /X{+|-} e[X]pandieren (+) oder Packen (-) der uebergebenen Dateien. Diesen Switch verwendet man, um Dateien zu entpacken. lxLite kann sowohl Dateien, die es selbst komprimiert hat, als auch solche, die von anderen Programmen mit den Standardmethoden gepackt wurden. (i.e. Resource Compiler, LINK386, REPACK). /X- ist nicht identisch mit der /cUnpack Option. /Z{#} Diese Option setzt den `threshold` fuer lxLite und hilft so festzustellen, ob eine Stub ein `dummy` ist oder ob er eine spezielle Funktion hat. Es gibt einige Programme (zum Beispiel, \os2\xdfloppy.exe) die sowohl unter DOS als auch unter OS/2 laufen - in solchen Programmen ist die DOS Executable in der OS/2` LX als ein DOS stub implementiert. Standardmaessig (wenn man einfach /Z benutzt) lxLite haelt jeden Stubs der groesser als 1024 Bytes ist, fuer einen funktionellen, und daher hat die /T{#} Option auf diese keinen Effekt. /?,/H Zeigt eine kurze Hilfe an. Diese ist ganz brauchbar, wenn man einen Switch aus der ganzen Liste vergessen hat:-) --------------------------------------------------------------------------- Das .CFG Dateiformat ist so simpel wie moeglich: Es ist eine reine ASCII Textdatei, welche mit jedem beliebigen Texteditor bearbeitet werden kann. Jedes Zeichen nach einem Strichpunkt ';' wird ignoriert, i.e. damit koennen Kommentare in die Konfigurationsdatei eingesetzt werden: ; Diese Zeile ist ein Kommentar Jede Zeile, die mit einem Wort und einem Doppelpunkt beginnt (z.B.: "Wort:") wird als einzelne Konfiguration behandelt. Das Wort identifiziert die Konfiguration. Das ist ein Beispiel fuer einen Konfigurationseintrag: FAILSAFE: /APP /B- /G+ /R4 /MR2 /ML1 /P- /U+ /V- Wie man sieht stehen nach dem Doppelpunkt beliebige Switches, wie man sie auch in der Kommandozeile nach lxLite schreiben wuerde. Rekursive /C Optionen werden nicht ignoriert, so dass man mehrere Konfigurationen aneinander binden kann, aber die /C Option wird als letztes verarbeitet, das heisst von zwei ueberlappenden Optionen wird nur die letzte effektiv sein. Als Beispiel: here: /app /b- /g+ da : /ass /b+ /p+ /chere "lxLite /cda " ist also gleichbedeutend mit "lxLite /app /b- /p+ /g+". Man beachte, dass lxLite auch weitere Aufrufe auf dieselbe Konfiguration ignoriert, um unendliche Schleifen zu vermeiden. Das bedeutet, "lxLite /cOne /" wird die `One` Konfiguration nur EINMAL laden. 5. Fehlermeldungen ------------------ Wie die allermeisten normalen Programme erzeugt lxLite manchmal Fehlermeldungen :-) Manche von Ihnen erscheinen in aehnlichen Situationen haben aber unterschiedliche Ausloeser. Hier ist eine kurze Liste der haeufigsten Fehler: * Invalid Konfiguration Datei format: Ungueltiges Format der Konfigurationsdatei. Selbsterklaerend:-) * Error reading Konfiguration Datei: Diese Meldung wird nur generiert, wenn die Konfigurationsdatei phy- sisch nicht lesbar ist. Das Programm erzeugt keine Fehlermeldung falls die Konfigurationsdatei einfach fehlt. * Error writing Konfiguration Datei: Fehler beim Schreiben der Konfigurationsdatei. Selbsterklaerend:-) * Error reading executable Diese Meldung wird generiert, wenn die Programmdatei physisch nicht lesbar ist. * error writing executable Diese Meldung wird generiert, wenn die Programmdatei nicht mehr auf die Platte geschrieben werden kann. Das kann dann passieren, wenn auf der Platte zuwenig Platz ist, lxLite selbst ueberprueft das nicht. * invalid executable file format Die Datei ist nicht vom Format [L]inear E[x]ecutable. Bei EXE-Dateien kann diese Meldung auftreten, wenn sie im alten, '[N]ew [E]xe (bwhahaha)' Format sind oder eine DOS-EXE-Datei oder eine WinDOS- EXE- Datei. * unsupported executable format revision Diese Meldung wird generiert (vielleicht:-), wenn die Programmdatei eine andere Dateiformatrevision hat als 0. Da OS/2 Warp normalerweise nur mit Revision 0 arbeitet, duerfte dieser Fehler normalerweise nie auftreten. * invalid word/dword ordering in executable Die Datei verwendet die 'little-endian' Byte order. Wahrscheinlich ist sie nicht fuer eine Intel-Plattform-Maschine gedacht. * executable target ist an unsupported CPU type Das kann passieren, falls die Ziel CPU eine andere als 286, 386, 486 oder P5 ist. * executable target ist an unsupported OS Das heisst, dass die Programmdatei nicht fuer OS/2 ist. WinDOS 95 verwendet ein aehnliches Format, aber seine Kennung ist nicht LX sondern LE, daher sollte es normalerweise eine 'invalid format' Meldung geben. * unknown entry bundle type in executable * unknown page flags in executable * invalid object page detected in executable Diese alle bedeuten, dass lxLite etwas ueber die interne Struktur nicht versteht. Ich bitte um Benachrichtigung, falls jemand Dateien findet bei denen diese Fehlermeldungen auftreten. * nicht enough memory to load executable Ich glaube nicht, dass dieser Fehler unter OS/2 auftreten kann:-) Eher wird eine 'Kein Platz mehr im SWAPPER.DAT' Meldung auftauchen. Wie auch immer, ich finde, es war keine gute Idee der IBM-Programmierer einen Fehler zu erzeugen, statt auf die Speicheranfrage einfach einen NIL-Pointer zurueckzugeben:-( 6. To-do-Liste -------------- Das ist eine Liste aller Features, die plane in zukuenftigen Versionen einzubauen. Jede Anregung ist willkommen, wie man mich erreicht, siehe letztes Kapitel. * Vielleicht eine Moeglichkeit, den LX Stub in VX-REXX Programmen zu packen; Ich weiss nur nicht obs wirklich gebraucht wird, der Unterschied in der Groesse macht gerade mal 18K aus - lxLite kann das echte Programm nicht packen, da es 1.) ausserhalb der LX-Struktur ist 2.) irgendwie verschluesselt ist und solche Daten ueberhaupt nicht gepackt werden koennen, PKZIP nicht einmal PKZIP kann das. * Vielleicht eine 'extra-pack'-Option, ich haette da eine Idee, wie man Programmedateien wirklich klein kriegt (kleiner als DOS-Packer jeden- falls:-); diese Programme wuerden dann aber nicht so wie ueblich arbeiten - sie waeren immer 'unlocked' (siehe auch das UNLOCK-Utility) i.e. sie werden im Swapfile landen, wenn nicht genaug Speicher da ist, sie werden nicht langsamer, aber das Swapfile wuerde dramtisch wachsen, wenn so ein Programm gestartet wuerde. Daher, sagt mir ob ihr sowas haben wollt, wenns genug Nachfrage gibt, mache ich es. 7. Bekannte Fehler und Einschraenkungen -------------------------------------- Hier ist eine Liste von Programmen, die sich aus irgendeinem Grund nicht packen lassen, probieren sinnlos: * PMJPEG v1.5 bis 1.74. Wie auch immer, sogar IBM`s REPACK kann es nicht packen, ich denke, dass es sich entweder um einen Bug im Linker, der benutzt wurde, um es zu generieren (die ganze EXE hat eine seltsame Struktur) oder eine Art debug-Schutz (Pruefsummen?). * VX-REXX-Programme. Der Hauptteil des Programms (der verschluesslte REXX-Code) wird einfach an einen kleinen LX-Stub angehaengt. Diese Programme haben eine unbekannte Struktur und wenn lxLite den Stub komprimiert, funktionieren sie ueberhaupt nicht mehr. * Watcom C & C++ v>=10.0. Schaut so aus als wuerde Watcom gerne Muell an die Dateien anhaengen. Diese Dateien sind dafuer gedacht, sowohl unter DOS als auch unter OS/2 zu laufen und haben ebenfalls eine seltsame Struktur. * ZIPBRAND v1.11. Es ueberprueft, ob sein .EXE-File veraendert wurde, vermutet einen Virus und will dann nicht mehr laufen [Ergaenzung des Ueber- setzers]. * InterCom. 8. Den Autor kontaktieren ------------------------- Via Email bin unter folgenden Adressen erreichbar: FIDOnet: 2:5030/84.5 (ist mir am Liebsten) Internet: bit@freya.etu.ru Enjoy, _\ndy 9. Der Uebersetzer ----------------- Ich war von Andys Programm so begeistert, dass ich ihm spontan angeboten habe, fuer ihn die Dokumentation der Version 1.01 ins Deutsche zu ueber- setzen. Manches klingt etwas holprig, aber erstens mache ich das nur hobbymaessig, zweitens bin ich kein professioneller Programmierer. Aber ich hoffe, es hilft trotzdem etwas. Die Uebersetzung zu 1.1.5 ist bereits ein kleines bisschen weniger holprig und enthaelt etwa 60 Tippfehler weniger als die zu 1.0.1. Via Email bin unter folgenden Adressen erreichbar (obwohl das ziemlich sinnlos ist, da ich ausser der Uebersetzung nichts beigesteuert habe): FIDOnet: Herwig Bauernfeind, 2:312/5.35 (ist auch mir am Liebsten) InterNet: H_BFD@fidonet.at (funktioniert zur Zeit aber nicht so gut) ΓòÉΓòÉΓòÉ 1.6. Error messages ΓòÉΓòÉΓòÉ Error messages Like most normal programs :-) lxLite can eventually generate error messages. Some of them can appear in similar conditions, but caused by different causes. Here is a short list of the most frequent errors: Invalid configuration file format Self-explaining, I think :-) Error reading configuration file Self explaining. error reading executable This is generated if executable is physically unreadable. error writing executable This is generated if executable cannot be written onto disk. The cause can be the insufficience of disk space - lxLite does not check for this particular error. invalid executable file format The file is not in [L]inear [E]xecutable. Note that you can get this message for files with .EXE extension in the cause they are in old, 'New Exe' (bwhahaha) format or DOS executable or winDOS executable. unsupported executable format revision This error can happen (may be :-) if you try to process an executable with other revision number than 0. OS/2 Warp works only with revision 0, so you will not normally encounter this problem. invalid word/dword ordering in executable The executable uses little-endian byte order. Seems that it is not for Intel platform machines. executable target is an unsupported CPU type This happen if the target CPU is other than 286, 386, 486 or P5. executable target is an unsupported OS This mean that the executable is not for OS/2. Windos and windos 95 uses similar format, but its magic number is not `LX` but `LE`, so usualy program will abort with an `invalid format` error. unknown entry bundle type in executable unknown page flags in executable invalid object page detected in executable It`s something about internal structure that lxLite doesnt know about. Please mail me if you encounter such files. not enough memory to load executable I doubt this error can happen in OS/2 :-) Rather a swap-file full fault will occur. BTW, it`s a bad idea of IBM programmers to trap instead of returning NIL pointer on a memory request :-( invalid stub Stub size must be greater or equal to 64 bytes. This requirement is due to limitation that offset to LX header must reside on the offset 60 in the stub; however it is unlikely that you`ll got this message since lxLite will add trailing zeros to such stubs. error reading EAs Cannot explain :-) error writing EAs this one too :-) invalid fixup record lxLite above 1.1.8 will depack and try to re-pack fixup records. Previous versions just read/write fixup table as a bunch of bytes; new versions will try to see what they contain. This error can happen when converting NE files since some of them ( TFTP.EXE for example) contains so-called OSFIXUP records that is outdated and don`t have analogue in LX executable format. However, these executables are seldom encountered (I`ve seen only mentioned TFTP). I don`t know an workaround for this: you cannot convert such NE files. bound application Executable is an bound application. Bound application is an NE executable which runs both in DOS and OS/2 mode. These are NOT two different executables bundled together (as most dual-mode programs are done: you can do this with lxLite inserting an different DOS stub into LX executable) but rather an tiny 'OS/2 emulator for DOS mode' binded together with NE file. These are usually programs with the simplest possible user interface - such as most executables from MASM 6.0 package. These executables can still be converted by overriding this with the /NB+ option, but they won`t run in DOS mode anymore. doesn`t support long filenames Executable is not long file name - aware. NE files uses a bit in NE header which shows whenever executables handle long file names. If it isn`t, OS/2 doesn`t show him LFN (just as for DOS programs). In some (most that I seen) cases this is of no importance since such executables doesn`t work with files (for example ARP.EXE or INETD.EXE from TCP/IP). You can override this error message by using the /NL+ option. incompatible segment definition NE executable contains an segment which don`t have direct analogue in LX executable format. This is done mostly since I haven`t seen executables with such segments (namely GDT and HUGE). If you encounter any, let me know, please. bad executable segment Executables contain an bad segment definition (either it is bigger than its declared size, or it is partially (or fully) out of executable file). If it works, I will be surprised :-) ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Title page | Introduction | Features | Command-line switches | Configuration file | Bugs and limitations | Thanks... | Utility Pack | Author info ΓòÉΓòÉΓòÉ 1.7. Features ΓòÉΓòÉΓòÉ Features lxLite compresses the files in the same way as LINK386 does. There is NO way of implementing an effective (by memory requirements) compression method other than those two which Warp kernel knows and will recognize (or the only for 2.x) since unlike DOS OS/2 does paging and pages are loaded by kernel paging mechanism which runs at ring 0. There is no documented way to intrude inside the OS/2 kernel even from device drivers (which also runs in ring 0). So, here is a brief description of these two algorithms: 1. Run-length packing. This is generally the same method that Microsoft C for DOS uses. It gives VERY bad results because the structure of executable files aren`t suited for that kind of packing. For example, PCX files uses approximatively the same packing method. 2. Kinda Lempel-Ziv algorithm. Lempel-Ziv is the same method which almost all DOS executables packers use - LZEXE, PKLITE, PGMPAK etc. The method standartized for OS/2 executable files is not the most effective (IMHO). Other thing is that OS/2 executable have a different loading algorithm in contrast to DOS executables - parts of OS/2 executables are loaded only when they are needed. So, Lempel-Ziv dictionary cannot cross the bound of a single page (4096 bytes). Because of this, it gives not such good results as it can. lxLite can use any of these two methods either for packing or unpacking. Generally the second gives best compression rates, but may be (?) there are some files on which first will work better. Because of this the default is to try to pack page using both methods and then choose the smaller result. lxLite can be used as well for unpacking the files that previously have been packed - either by lxLite, LINK386 or REPACK from IBM. In some (seldom) cases you should specify the /F (force) option to force repacking - otherwise lxLite can give the "module is already packed" message. What kind of files you can compress? The LX format is used almost everywhere in OS/2: almost everything is in LX format. So, you don`t have to limit only to .EXE files: you can pack .DLL, .PDR, .QPR, .DRV, .FON, .SYS (Virtual Device Drivers (VDDs) in \OS2\MDOS) as well. You can run lxLite on virtually any file: if it is not in Linear Executable (LX) format it will fail to process it. Versions above 1.1.7 of lxLite can also convert to LX and compress most NE executables: this is a tricky thing but seems that in most cases it works well. If it cannot be acomplished, lxLite will give you an error message. If you don`t like this, you can disable this by using the /N- option on the command line. By default lxLite will convert *only* .EXE and .DLL files, which doesn`t contain resources, are long-filenames aware (.EXEs) and are not 'bound executable's (.EXEs). Some conversion considerations: NE files have a bit in the header that shows if the module handles long file names (since OS/2 v1.0 didn`t have long file names: HPFS was introduced in version 1.2). Executables with this bit set will see files with LFNs, when this bit is not set whey will work just like DOS programs do, i.e. won`t see files with LFN. Many NE executables doesn`t have this bit set, although they don`t care at all about filenames (for example, ARP.EXE, IFCONFIG.EXE from TCP/IP). Moreover, many executables that even works with file names will work as well with the long file names (for example I tried some UUENCODE/UUDECODE clones). By default lxLite will fail to convert such files into LX since LX modules doesn`t have such a bit in header, but you can force conversion by using the /NL switch. Default configuration file instructs lxLite to ignore this bit for all known to me kinds of dynamic-link libraries: DLL, DRV, FON, PDR, QPR (although last four extensions, as far as I know, always are LX modules). Also there is a number of NE executables (for example most EXEs from SIO or MASM 6.0 package) which are so-called 'bounded' (also known as "Family API") executables. A bounded executable can run both under DOS and OS/2, but not the way as LX modules do (one file contains TWO different executables; DOS executable is binded as stub to OS/2 LX executable), but other way: DOS stub is a small program which loads and executes NE executable under plain DOS, and emulates a (very) limited set of OS/2 API calls via BIOS and DOS interrupts. By default lxLite will also fail to convert such executables into LX modules since resulting executables won`t run under DOS anymore: however, if you have PROTECTONLY=YES in CONFIG.SYS or simply don`t need the executable to run under DOS, you can change the behavior of lxLite using the /NB switch on the command line. Another incompatibility between LX and NE files are resources. If NE module contains resources and they`re loaded using the Dos16GetResource API function, API will return an error code when trying to load same resources from an LX file. So, by default, lxLite will fail to convert NE modules that contains resources (however, there are not too much such modules). However, you can override this by using the /NR switch. As a example of a DLL with resources you can look at \TCPIP\DLL\TCPMRI.DLL. Many NE utilites (such as ARP, PING etc) uses Dos16GetResource to load resources from TCPMRI.DLL, and will display an 'Failure in national language support' instead of almost all messages. There is an alternative API function for 16-bit modules: DosGetResource2, which will work well for an LX file. So if you`re sure that all resources in a file are loaded exclusively through DosLoadModule2, you can force lxLite to convert such NE files by using the /NR switch. lxLite version 1.00 and above can replace executable modules even if they are currently in use. In this case it will warn you that module is already in use by another process, and will propose you either to replace it by its packed version or either to skip this module. Choose at your wish, but keep in mind that the modules you have replaced are kept now (their old versions) in memory, so they eat up your swapfile space. Better reboot as soon as you have this opportunity. You can also consider compressing your entire \OS2\*\ directory structure, it will give you a lot of extra space and absolutely no overhead! The time spent for decompressing executables is recovered by the time which system does not spend for reading the executable from HD because it`s much smaller! You can even compress the DLLs which are currently locked (lxLite will unlock them, but swap file will increase, so you will need to reboot after this). For this, you have to type: lxLite #:\os2\* /r /yur where # is drive letter of your boot drive. Version 1.1.0 and above detects executables which contains some data after the LX structure itself (i.e. what`s called in DOS overlay data). For example Watcom`s binded executables (such as WCC.EXE versions >= 10.0) and Watcom Visual Rexx executables have such structure. In this case lxLite shows an warning message and asks for confirmation whenever you really want to pack such executable. It is STRONGLY recommended that you backup the executable in question before trying to do it because it is VERY possible that it will become non-functional if something gets changed in it (because lxLite does not change any of possible pointers in data binded to LX as in VREXX executables). Default configuration file instructs lxLite to back up automatically such executables (by using the /BX switch). All backed up filenames are stored by default into the \lxLite.bak directory. ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Title page | Introduction | Command-line switches | Configuration file | Error messages | Bugs and limitations | Thanks... | Utility Pack | Author info ΓòÉΓòÉΓòÉ 1.8. Introduction ΓòÉΓòÉΓòÉ Introduction I think all of us end-users are really bored of the big size and reduced functionality of all those modern executables written to run under OS/2 (windos too). I don`t understand why they are so big, because most compilers, even IBM CSet/VACPP generate a modest size code. For a widely known example let`s take MultiMaint. What a complex task it performs that its executable occupies more that 700K? I don`t understand. Moreover, WHY duplicate (and triplicate) almost the same executable as it does (I mean MultiSafe and IniMaint which comes along with MultiMaint). It performs a nice work, but it is TOO big for the task it acomplishes. OS/2 kernel have the same size, and performs INCOMPARABLY much more things. I cannot afford such a large pile of shit on my HD, so I killed MultiMaint & C┬░. :`-(. Too bad for its author. ; Here is a workaround for this. You can just pack the executable so it will be twice smaller and still perform the same task. Alas, it will grab the same amount of memory as original executable does - this is the fault of the program`s author. But it will load (and swap) faster in most cases (unless you have a Fast UltraWide SCSI 2 HD :-) As far as I know there is only one program which does the same - REPACK from IBM (EWS?). But compared to lxLite it gives less compression using same algorithm. For example, COURIER.FON from OS/2 v8.192 it compresses into 44K and lxLite into 34K. Feel the difference. BTW, LINK386+Resource Compiler compiles COURIER.FON also into 44K-size file. This makes me think that they use the same common compression code. I`ve packed ALL my executables (incuding but not limiting to ?:\os2\*.exe, ?:\os2\dll\*.* and ?:\os2\dll\ibmnull;laserjet) and my system is stiil working fine :-) One of lxLite users (Pavel Roskin) observed that lxLite packs even os2krnl :-) This is a very nice feature to create a SINGLE OS/2 boot diskette, moreover, since version 1.1.8 lxLite has the ability to pack even device drivers, so you can even gain a little of free space on that diskette, enough to put there say FC/2 or other text-mode shell. ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Title page | Features | Command-line switches | Configuration file | Error messages | Bugs and limitations | Thanks... | Utility Pack | Author info ΓòÉΓòÉΓòÉ 1.9. lxLite_ru.txt ΓòÉΓòÉΓòÉ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ LX lite - ╨┐╨░╨║╨╛╨▓╤ë╨╕╨║ ╨┤╨╗╤Å ╨▓╤ï╨┐╨╛╨╗╨╜╤Å╨╡╨╝╤ï╤à ╤ä╨░╨╣╨╗╨╛╨▓ OS/2 ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ * ╨¡╤é╨╛╤é ╤é╨╡╨║╤ü╤é - ╨▓╤ü╨╡╨│╨╛ ╨╗╨╕╤ê╤î ╤ü╨╛╨║╤Ç╨░╤ë╨╡╨╜╨╜╨░╤Å ╨▓╨╡╤Ç╤ü╨╕╤Å ╨░╨╜╨│╨╗╨╕╨╣╤ü╨║╨╛╨╣ ╨┤╨╛╨║╤â╨╝╨╡╨╜╤é╨░╤å╨╕╨╕. ╨ö╨╗╤Å ╨┐╨╛╨╗╤â╤ç╨╡╨╜╨╕╤Å ╨┐╨╛╨╗╨╜╨╛╨╣ ╨╕╨╜╤ä╨╛╤Ç╨╝╨░╤å╨╕╨╕ ╨┐╨╛ ╨┤╨░╨╜╨╜╨╛╨╣ ╨┐╤Ç╨╛╨│╤Ç╨░╨╝╨╝╨╡ ╨╛╨▒╤Ç╨░╤ë╨░╨╣╤é╨╡╤ü╤î ╨║ ╨╜╨╡╨╣. ╨ù╨┤╨╡╤ü╤î ╨╢╨╡ ╨┐╤Ç╨╕╨▓╨╡╨┤╨╡╨╜╤ï ╤é╨╛╨╗╤î╨║╨╛ ╨╛╤ü╨╜╨╛╨▓╨╜╤ï╨╡ ╨╝╨╛╨╝╨╡╨╜╤é╤ï ╨╛╤é╤Ç╨░╨╢╨╡╨╜╨╜╤ï╨╡ ╨▓ ╨░╨╜╨│╨╗╨╕╨╣╤ü╨║╨╛╨╣ ╨▓╨╡╤Ç╤ü╨╕╨╕. ╨¥╨░╨┤╨╡╤Ä╤ü╤î ╤ç╤é╨╛ ╨╝╨╛╨╣ ╤â╨▒╨╛╨│╨╕╨╣ ╨░╨╜╨│╨╗╨╕╨╣╤ü╨║╨╕╨╣ ╨╜╨╡ ╨┐╨╛╨╝╨╡╤ê╨░╨╡╤é ╨Æ╨░╨╝ ╨┐╨╛╨╜╤Å╤é╤î ╤ç╤é╨╛ ╨╢╨╡ ╤é╨░╨╝ ╨╜╨░ ╤ü╨░╨╝╨╛╨╝ ╨┤╨╡╨╗╨╡ ╨╜╨░╨┐╨╕╤ü╨░╨╜╨╛. 1. ╨Æ╤ü╤é╤â╨┐╨╗╨╡╨╜╨╕╨╡ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ╨£╨╡╨╜╤Å ╨╛╤é╨║╤Ç╨╛╨▓╨╡╨╜╨╜╨╛ ╨┤╨╛╤ü╤é╨░╨╗╨╕ :-) ╨╛╨│╤Ç╨╛╨╝╨╜╤ï╨╡ ╤Ç╨░╨╖╨╝╨╡╤Ç╤ï ╤ü╨╛╨▓╤Ç╨╡╨╝╨╡╨╜╨╜╤ï╤à ╨┐╤Ç╨╛╨│╤Ç╨░╨╝╨╝, ╨┐╤Ç╨╕ ╨╕╤à ╨╛╨│╤Ç╨░╨╜╨╕╤ç╨╡╨╜╨╜╨╛╨╣ ╤ä╤â╨╜╨║╤å╨╕╨╛╨╜╨░╨╗╤î╨╜╨╛╤ü╤é╨╕. ╨ƒ╨╛╤ì╤é╨╛╨╝╤â ╤Å ╤â╨╢╨╡ ╨┐╨╛╤ç╤é╨╕ ╨│╨╛╨┤ ╨╝╨╡╤ç╤é╨░╤Ä ╨╛ ╨┐╤Ç╨╛╨│╤Ç╨░╨╝╨╝╨╡ ╨┤╨╗╤Å OS/2 ╨║╨╛╤é╨╛╤Ç╨░╤Å ╨▒╤ï ╨┤╨╡╨╗╨░╨╗╨░ ╨┤╨╗╤Å OS/2 ╤é╨╛ ╨╢╨╡ ╤ç╤é╨╛ ╨┤╨╗╤Å DOS - lzexe, pklite, diet, compack, ainexe ╨╕ ╨╝╨╜╨╛╨│╨╛-╨╝╨╜╨╛╨│╨╛ ╨┤╤Ç╤â╨│╨╕╤à. ╨₧╨┤╨╜╨░╨║╨╛ ╨╛╨╜╨░ ╨▓╤ü╨╡ ╨╖╨░╨┤╨╡╤Ç╨╢╨╕╨▓╨░╨╗╨░╤ü╤î. ╨ƒ╤Ç╨░╨▓╨┤╨░ ╨┐╤Ç╨╕╨╝╨╡╤Ç╨╜╨╛ ╨▓ ╨┤╨╡╨║╨░╨▒╤Ç╨╡ ╨┐╨╛ MFE.OS2 ╨┐╤Ç╨╛╤à╨╛╨┤╨╕╨╗╨░ ╨┐╤Ç╨╛╨│╤Ç╨░╨╝╨╝╨░ REPACK ╨║╨╛╤é╨╛╤Ç╨░╤Å ╨▓╤Ç╨╛╨┤╨╡ ╨▒╤ï ╤ç╨░╤ü╤é╨╕╤ç╨╜╨╛ ╤Ç╨╡╤ê╨░╨╗╨░ ╨┐╤Ç╨╛╨▒╨╗╨╡╨╝╤â, ╨┐╨╡╤Ç╨╡╨┐╨░╨║╨╛╨▓╤ï╨▓╨░╤Å exe`╤ê╨╜╨╕╨║╨╕ ╨┐╤Ç╨╕╨╝╨╡╤Ç╨╜╨╛ ╤é╨░╨║ ╨╢╨╡ ╨║╨░╨║ ╤ì╤é╨╛ ╨┤╨╡╨╗╨░╨╡╤é LINK386 ╤ü ╨╛╨┐╤å╨╕╨╡╨╣ /EXEPACK:2. ╨₧╨┤╨╜╨░╨║╨╛ ╤â╨▒╨╛╨│╨╕╨╣ ╨╕╨╜╤é╨╡╤Ç╤ä╨╡╨╣╤ü :-) ╨╕ ╨┐╨╛╨╗╨╜╨╛╨╡ ╨╛╤é╤ü╤â╤é╤ü╤é╨▓╨╕╤Å ╨╛╨┐╤å╨╕╨╣ ╨▓ ╨╜╨╡╨╣ ╨╝╨╡╨╜╤Å ╨╛╨║╨╛╨╜╤ç╨░╤é╨╡╨╗╤î╨╜╨╛ ╨┤╨╛╤ü╤é╨░╨╗╨╛, ╨╕ ╤Å ╤Ç╨╡╤ê╨╕╨╗╤ü╤Å ╨▓╨╖╤Å╤é╤î╤ü╤Å ╨╖╨░ ╨┤╨╡╨╗╨╛ ╤ü╨╛╨▒╤ü╤é╨▓╨╡╨╜╨╛╤Ç╤â╤ç╨╜╨╛ (╨▓╨░╤Ç╨╕╨░╨╜╤é: ╤ü╨╛╨▒╤ü╤é╨▓╨╡╨╜╨╜╨╛╨╜╨╛╨╢╨╜╨╛ ;-). ╨ƒ╨╛╨┐╤â╤é╨╜╨╛ ╨╛╨║╨░╨╖╨░╨╗╨╛╤ü╤î ╤ç╤é╨╛ REPACK ╨▓╤ï╨╢╨╕╨╝╨░╨╡╤é ╨┤╨░╨╗╨╡╨║╨╛ ╨╜╨╡ ╨▓╤ü╨╡ ╨▓╨╛╨╖╨╝╨╛╨╢╨╜╨╛╨╡ ╨╕╨╖ ╨╛╨┐╤å╨╕╨╕ /EXEPACK:2. lxLite ╨┐╨░╨║╤â╨╡╤é ╨▓ ╤ü╤Ç╨╡╨┤╨╜╨╡╨╝ ╨┐╤Ç╨╛╤å╨╡╨╜╤é╨╛╨▓ ╨╜╨░ 10 ╨╗╤â╤ç╤ê╨╡ ╤ç╨╡╨╝ REPACK, ╤ç╤é╨╛ ╨▓ ╤ü╤â╨╝╨╝╨╡ ╨┤╨░╨╡╤é ╨▓╨╡╤ü╤î╨╝╨░ ╨╜╨╡╨┐╨╗╨╛╤à╨╛╨╣ ╨▓╤ï╨╕╨│╤Ç╤ï╤ê. ╨¥╨░╨┐╤Ç╨╕╨╝╨╡╤Ç ╤ü╤é╨░╨╜╨┤╨░╤Ç╤é╨╜╤ï╨╣ COURIER.FON ╤â ╨╝╨╡╨╜╤Å ╨╖╨░╨╜╨╕╨╝╨░╨╗ 44K (╨┐╨░╨║╨╛╨▓╨░╨╜╨╜╤ï╨╣ REPACK`╨╛╨╝) - ╨┐╨╛╤ü╨╗╨╡ lxLite ╨╛╨╜ ╤ü╤é╨░╨╗ ╨╖╨░╨╜╨╕╨╝╨░╤é╤î 34K. ╨ƒ╨╛╤ç╤â╨▓╤ü╤é╨▓╤â╨╣╤é╨╡ ╤Ç╨░╨╖╨╜╨╕╤å╤â :-) ╨¥╤â ╨╕ ╨┤╤Ç╤â╨│╨╕╨╡ ╨┐╨╗╤Ä╤ü╤ï lxLite - ╨┐╨╛╨▓╤ï╤ê╨╡╨╜╨╜╨░╤Å ╨║╨╛╨╜╤ä╨╕╨│╤â╤Ç╨░╨▒╨╡╨╗╤î╨╜╨╛╤ü╤é╤î, ╨╜╨░╨╗╨╕╤ç╨╕╨╡ ╨╜╨╡╨║╨╛╤é╨╛╤Ç╨╛╨╣ ╨┤╨╛╨┐╨╛╨╗╨╜╨╕╤é╨╡╨╗╤î╨╜╨╛╨╣ ╨╕╨╜╤ä╨╛╤Ç╨╝╨░╤å╨╕╨╕ ╨▓╨╛ ╨▓╤Ç╨╡╨╝╤Å ╨╛╨┐╨╡╤Ç╨░╤å╨╕╨╕ ╨┐╨░╨║╨╛╨▓╨║╨╕, ╨▓╨╛╨╖╨╝╨╛╨╢╨╜╨╛╤ü╤é╤î ╨▓╤ï╨▓╨╛╨┤╨░ ╨╜╨╡╨║╨╛╤é╨╛╤Ç╨╛╨╣ ╨╕╨╜╤ä╨╛╤Ç╨╝╨░╤å╨╕╨╕ ╨╛ ╨╛╨▒╤Ç╨░╨▒╨░╤é╤ï╨▓╨░╨╡╨╝╨╛╨╝ exe`╤ê╨╜╨╕╨║╨╡ (╨┤╨╗╤Å ╨╗╤Ä╨▒╨╛╨┐╤ï╤é╨╜╤ï╤à :-) - ╤Å ╨┤╤â╨╝╨░╤Ä ╨▓╤ï ╨╛╤å╨╡╨╜╨╕╤é╨╡ ╨▓ ╨┐╤Ç╨╛╤å╨╡╤ü╤ü╨╡ ╤ì╨║╤ü╨┐╨╗╤â╨░╤é╨░╤å╨╕╨╕. ╨ò╤ü╨╗╨╕ ╨║╤é╨╛-╤é╨╛ ╤ü╤ç╨╕╤é╨░╨╡╤é ╤ç╤é╨╛ ╤â╨╝╨╡╨╜╤î╤ê╨╡╨╜╨╕╨╡ EXE`╤ê╨╜╨╕╨║╨╛╨▓ ╨▓ ╤Ç╨░╨╖╨╝╨╡╤Ç╨╡ ╨▓ ╤ü╤Ç╨╡╨┤╨╜╨╡╨╝ ╤Ç╨░╨╖╨░ ╨▓ ╨┤╨▓╨░ - ╤ì╤é╨╛ ╨║╤Ç╨╛╤à╨╛╨▒╨╛╤Ç╤ü╤é╨▓╨╛, ╤é╨╛ ╤ì╤é╨░ ╨┐╤Ç╨╛╨│╤Ç╨░╨╝╨╝╨░ ╤Å╨▓╨╜╨╛ ╨╜╨╡ ╨┤╨╗╤Å ╨Æ╨░╤ü. lxLite ╨┐╤Ç╨╛╨▓╨╡╤Ç╨╡╨╜ ╨▓ ╤Ç╨░╨▒╨╛╤é╨╡ ╨╜╨░ ╨┐╤Ç╨░╨║╤é╨╕╤ç╨╡╤ü╨║╨╕ ╨Æ╨í╨ò╨Ñ ╨╝╨╛╨╕╤à ╨▓╤ï╨┐╨╛╨╗╨╜╤Å╨╡╨╝╤ï╤à ╤ä╨░╨╣╨╗╨░╤à ╨┤╨╗╤Å OS/2 (╨▓ ╤é╨╛╨╝ ╤ç╨╕╤ü╨╗╨╡ ╨╜╨░ c:\os2\*.exe; c:\os2\dll\*\*.*; ╨╖╨░╨▒╨░╨▓╨╜╨╡╨╡ ╨▓╤ü╨╡╨│╨╛ ╤ç╤é╨╛ ╨┐╨░╨║╤â╨╡╤é╤ü╤Å ╨┤╨░╨╢╨╡ OS2KRNL /thx to Pavel Roskin/) ╨╕ ╨║╨░╨║ ╨╜╨╕ ╤ü╤é╤Ç╨░╨╜╨╜╨╛ ╨▓╤ü╨╡ ╤Ç╨░╨▒╨╛╤é╨░╨╡╤é. ╨ƒ╨╛╨┤╤Ç╨╛╨▒╨╜╨╡╨╡ ╨╛╨▒ ╨╛╨┐╤å╨╕╤Å╤à lxLite ╨╕ ╨▓╤ï╨┐╨╛╨╗╨╜╤Å╨╡╨╝╤ï╤à ╨╕╨╝╨╕ ╤ä╤â╨╜╨║╤å╨╕╤Å╤à ╨╝╨╛╨╢╨╜╨╛ ╨┐╤Ç╨╛╤ç╨╡╤ü╤é╤î ╨▓ ╨░╨╜╨│╨╗╨╕╨╣╤ü╨║╨╛╨╣ ╨┤╨╛╨║╤â╨╝╨╡╨╜╤é╨░╤å╨╕╨╕. ╨ò╤ü╨╗╨╕ ╨╢╨╡ ╨Æ╤ï ╨╜╨╡ ╨╖╨╜╨░╨╡╤é╨╡ ╨░╨╜╨│╨╗╨╕╨╣╤ü╨║╨╛╨│╨╛, ╨╜╨╡ ╨╛╨│╨╛╤Ç╤ç╨░╨╣╤é╨╡╤ü╤î - ╤ü╨║╨╛╤Ç╨╡╨╡ ╨▓╤ü╨╡╨│╨╛ ╤ì╤é╨╕ ╨╛╨┐╤å╨╕╨╕ ╨Æ╨░╨╝ ╨╜╨╡ ╨╜╤â╨╢╨╜╤ï. ╨ö╨╗╤Å ╨╛╨▒╤ï╤ç╨╜╨╛╨│╨╛ ╨╖╨░╨┐╤â╤ü╨║╨░ lxLite ╨┐╤Ç╨╛╤ü╤é╨╛ ╨╜╨░╨▒╨╡╤Ç╨╕╤é╨╡ lxLite *.exe *.dll ╨▓ ╨║╨░╤é╨░╨╗╨╛╨│╨╡ ╨▓ ╨║╨╛╤é╨╛╤Ç╨╛╨╝ ╤â ╨Æ╨░╤ü ╨╜╨░╤à╨╛╨┤╤Å╤é╤ü╤Å ╨▓╤ï╨┐╨╛╨╗╨╜╤Å╨╡╨╝╤ï╨╡ ╤ä╨░╨╣╨╗╤ï OS/2. ╨ò╤ü╨╗╨╕ ╨╢╨╡ ╨Æ╨░╨╝ ╤à╨╛╤ç╨╡╤é╤ü╤Å ╤Ç╨░╤ü╨┐╨░╨║╨╛╨▓╨░╤é╤î ╤ä╨░╨╣╨╗(╤ï) ╨╜╨░╨▒╨╡╤Ç╨╕╤é╨╡ ╤é╨╛ ╨╢╨╡ ╤ü╨░╨╝╨╛╨╡ ╨╜╨╛ ╨┤╨╛╨▒╨░╨▓╤î╤é╨╡ /x. ╨í╤ç╨░╤ü╤é╨╗╨╕╨▓╨╛╨│╨╛ ╨┐╨╛╨╗╤î╨╖╨╛╨▓╨░╨╜╨╕╤Å. ╨É╨╜╨┤╤Ç╨╡╨╣ ╨ù╨░╨▒╨╛╨╗╨╛╤é╨╜╤ï╨╣, FIDOnet: 2:5030/84.5 e-mail: bit@freya.etu.ru ΓòÉΓòÉΓòÉ 1.10. Command-line switches ΓòÉΓòÉΓòÉ Command-line switches There are a lot of options in lxLite. I simply like options :-) So, you can configure almost anything in lxLite. Moreover, to protect the user from need of writing the same options lxLite support multiple configurations which are kept in a single file. lxLite comes with some example configurations (`factory defaults`) which are listed below: ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ default (loaded by default) It is a `work` configuration. All parameters are set to optimal level of compression without too much effort applied. File backup is disabled except for files that have extra data after LX structure. Note that this configuration is ALWAYS loaded before any other options are in effect, so even /C{#} option is executed AFTER default configuration is loaded. unpack (loaded for /X option) This configuration is loaded when you request to unpack the file (/X). By default it is empty; you can add here everything you want to happen when files are unpacked. ver2x Optimal for pre-Warp versions of OS/2. Versions before Warp (3.0) does not know of the Lempel-Ziv (/EXEPACK:2) method. DON`T PACK EXECUTABLES WITH LEMPEL-ZIV`s ALGORITHM if there is a chance to run your program on OS/2 v2.xx (except 2.99). max Tightest compression level. VERY SLOW! It is rarely needed to use this configuration. newStub This is a particular configuration used to replace one DOS stub in LX executable by another without altering anything else. You have to specify a filename for new stub - this configuration only tells lxLite not to depack old objects and not to pack unpacked objects. minStub This is a configuration which is linked to newStub and replaces stubs in given files by minimal possible stub of `say-error-and-exit` type. You cannot make it smaller (at least I doubt it), only if you shorten the error message. vdmStub This configuration tells lxLite to replace in specified files stub by a `run-from-VDM`-style one. This is also as short as possible :-) Please read the /T{#} option description for further details. info Use this configuration to get the most important information about executables (see option /V) without altering them. exehdr Shows complete information about the executable header. Module file is not altered in any way. exemap Shows anything about the executable structure. This can generate sometimes very long data sheets, so use it only if really needed. map Shows the memory map of the executable: memory objects and pages which makes the object. exp Shows everything that is exported from the module (exported names and exported entriy points) imp Shows module import tables pdd This configuration can be used for physical device drivers (especially in NE format). dll This configuration is useful for dynamic-link libraries. ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ To use a specific configuration use the /C:# switch where # is configuration`s identifier. Settings are loaded from file lxLite.CFG in the same directory where lxLite.EXE resides. You shouldn`t care about paths - lxLite will always find it. For example, to use `max` configuration run lxLite /c:Max. For a detailed description of .CFG file format see section right below the following. Here is a detailed explanation of what each switch does. Note that any switch which accepts '+' or '-' sign after it (to enable/disable the action which switch symbolizes) can be used without anything after it - this is accepted as '+'. For example, /V+ is equivalent to /V. ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ /A[{P|S|N{P|S}}{:#}] Set alignment method for first and rest of objects. First object can be aligned on [P]age shift, [S]ector or [N]o boundary. Note that the last option (No boundary) cannot be achieved by using LINK386, but it works well, and the LX format allows it. All objects except first MUST be aligned on at least PageShift boundary. PageShift is a value that is specified in LX header. You can redefine it too by specifying a semicolon and a decimal value after it: for example the /APP:512 switch will place all pages in executable on 512 bytes boundary. Note that the # value must be a power of two (i.e. 1,2,4,8,16,32,...). /B(D|X|+|-){:%} Enable (+) or disable (-) copying original file into *.BAK; optionaly lxLite can do it only when [D]ebug and/or e[X]tra data are detected. Also you can specify an directory % for backed up files (relative to root). The entire directory tree will be re-created inside the backup directory. For example, the /BX:c:\lxlite.bak switch will instruct lxLite to back up files only when e[X]tra data is present in module and to place them into the directory structure under the c:\lxlite.bak directory. /C{S}{+|-} Enable (+) or disable (-) colored output. You can specify {S} to force lxLite to use StdOut instead of VioXXX functions. /C[:%] Use configuration with ID = %; The two predefined configuration names are "default" and "unpack". First is always loaded as lxLite starts and second is used when /X+ option is specified (this is NOT equivalent to /c:Unpack). / E{#} Set [E]xclude filemask. All files that fits given filemask(s) will be bypassed by lxLite. All filemasks must be separated by ':' (because it cannot be a part of filemask). For example /D*.zip:*.arj:*.rar switch will instruct lxLite to avoid all .zip, .arj and .rar files. Default lxlite configuration (/C:default) includes the /C:exclude configuration which instructs lxLite to avoid all executables which are known to have problems when packed. Note that the /D switches are additive, so /D*.zip /D*.arj /D*.rar is equivalent to the example above. To clear exclusion list use specify /D. /F{+|-} Force repacking. Use /F+ to bypass `already processed` message, i.e. when lxLite thinks that file was already processed and it really wasn`t. This usually doesn`t happen, but can happen when you try to replace a stub by another of the same size in a already packed file. /I{+|-} Force (+) lxLite to run at idle priority. This mean that lxLite will do its work only when no other activity in system occurs (waiting for an keyboard/mouse event etc). This is the best in my opinion choice because you can run lxLite in background and it will not degrade almost at all system performance. However if you`ll run an `badly-behaved` VDM session which grabs all CPU time lxLite will completely stop. When run with /I- option lxLite does not changes its priority (i.e. you can run lxLite /I- via priority.exe program which starts programs with given priority). /J[A|E|L|P|V](E|L|P|V|N|X|+|-) Change module type: Leave [A]s-is, [E]xecutable module, [L]ibrary module, [P]hysical or [V]irtual driver. Especially useful when converting NE drivers. Optionaly you can restrict this to work only on [E]xecutables, [L]ibraries, [P]hysical or [V]irtual drivers, [N]E or L[X] executables and any combination of them. [N]E and [L]X conditions are considered with an AND operator; all others with OR, i.e. /JPELN will mean: "Change module type into [P]hysical device driver for all [E]xecutables OR [L]ibraries which also are (AND) [N]E modules" /L(A|S|U|+|-){:%} Instructs lxLite to maintain an log file. If no file name is specified, lxLite.log is used in the home directory of lxLite. Beside the filename, the start and final file size is written into log along with the problems (if any) that were encountered when processing (for example: 'Executable has been used by another process and replaced'). You can also optionaly choose to log either [S]uccessful or [U]nsuccessful cases or [A]ll (which means more than just /SU+: lxLite will also log 'already processed' files). /M[R[N|1|2|3]|L[N|1]|F[N|1|2]] Set packing method & parameters. Second character (after M) defines the method to set-up: `R` stands for run-length (/EXEPACK:1), 'L' for Lempel-Ziv (/EXEPACK:2) and 'F' for Fixup packing method. The third character is the level of compression using that method; if N is specified the method is disabled. Three levels of packing are provided for run-length compression. The level 1 is the fastest. It searches only for 1-character strings. For example, the 'AAAAAAAA' string will be detected and packed as 8, 1, 'A' while 'ABABABAB' string will be stored as unpacked text. Level 2 detects repeated strings of up to 16 characters length, so the example above will be encoded as 4,2,'AB'. This is the default setting for most 'factory` configurations. And last, 3rd level searchs for ALL strings of any length (up to page size/2 = 2048). This compreses VERY slow and seldom gives real results, so use it only when you really need it. The Lempel-Ziv algorithm can be either disabled (/MLN) or enabled (/ML1). When enabled it searchs for all matches using a relatively fast hash-table, so there is no need in gradations by compression speed. The fixup packing method can be set to [N]one, level 1 end level 2; fixups packed using Level 1 are recognized by any OS/2 version above 2.x; however level 2 compressed fixups will work only in OS/2 Warp 3.0 with (fixpack #17 (I believe)) and above (Warp 4.0 too). Note that when /MF1 or /MF2 is in use, the /U{+|-} option is ignored - module is always unpacked first. /N(B|L|A|+|-) [N]E executables: convert into LX (+) or reject (-) modules that are [B]ound, not [L]FN-aware or [A]ll. For more information about [B] and [L] option see the 'Features' section above. For example, the /NA- option will instruct lxLite not to convert NE files into LX, the /NA+ will instruct to convert always; the /NA-LB+ will instruct lxLite to convert ONLY non-[L]FN-aware and [B]ound executables, the /NA+LB- will instruct lxLite to convert [A]ll except non-[L]FN-aware and [B]ound executables. /O(X|D|S|A|+|-){:%} [O]utput e[X]tra/[D]ebug/[S]tub data into an external file; filename is determined by applying mask % onto original filename. Data is written [A]lways in the A+ state and only when removed in the A- state. For example, the /OD:*.$d$ switch will have effect on the TEST.EXE executable which contains debug info only when you choose to discard it and will place it into the file TEST.$d$. /P{+|-} Enable (+) or disable (-) pause before each file. The program shows the name of file which will be processed and offers a choice to continue or to abort. /Q{+|-} Query all configuration options. Basically it simply types a colored version of lxLite.cfg file through a MORE-style filter :-) All other options on the command line (if any) are ignored. /R{+|-} Enable (+) or disable (-) [R]ecursive file search through subdirectories. /S{+|-} Show (+) or don`t show (-) configuration in effect. This is useful for examining which settings are stored into .CFG file, especially for linked configurations (see below). For example lxLite /Cdefault /S will show the default settings. /T{:%} Use specified file as new DOS stub. DOS stub is (usualy) a tiny DOS .EXE file linked to OS/2`s module which is typicaly used to type an error message in the case if the executable is not run from DOS command line. Usually this looks like: This is an OS/2 executable module Along with lxLite are enclosed two stubs: stub_min.bin and stub_vdm.bin. First is the standard `type-error-and-exit` type, but it is slightly smaller than usual stubs used by various linkers. The second is an stub which starts a new OS/2 session and runs program from it again. If OS/2 is not detected it types the same error message and exits. The default for stub_vdm.bin is to let OS/2 decide the type of your executable itself. Alternatively, you can specify the type of session to be started by stub_vdm.bin. For this you need any hex editor - find the pattern `SesType->' in stub and replace the byte that comes after arrow (->) by needed session type. OS/2 recognizes next session types: 00 - OS/2 session manager determines type (default) 01 - OS/2 full-screen session 02 - OS/2 windowed session 03 - PM application 04 - VDM full-screen session 07 - VDM windowed session You can use stubs to do some neat tricks. Say you have two executables: ZIP for OS/2 and ZIP for DOS (I mean GNU ZIP, not PKZIP). They offer the same interface, does the same thing and share the same name. To avoid conflicts (and avoid placing them in different directories) you can link them both together into one EXE file which can be ran either from DOS or OS/2 mode. This can be achieved by following command line: lxLite /t:dos\zip.exe os2\zip.exe If stub size is bigger than certain threshold size (default - 1024 bytes) it will not be replaced. This is done since stubs of bigger size usualy does something useful (for example, this can be already an 'dual-mode' executable). It is useful for batch conversions and not too useful when you do tricks like described above: so you can wish to change this threshold value to zero. This can be achieved using the /Z switch (see below for details). /U{+|-} Enable (+) or disable (-) unpacking file before packing. lxLite know how to unpack any of two packing methods described, so default option state is enabled. Disable it only when compression time savings are more important than disk space savings. This option is ignored (and file is anyway unpacked) when /MF2 packing is enabled. /V[{0123OCRNMPEF}{+|-}] [V]erbose (show a lot of file information). This is a switch for curious ones :-) It has different levels of verbosity, you can choose which kind of information to include in overall output. For example: /V0-12+3-O+. Here is an detailed description of what each key shows: 0 Show basical information about executable: - module type - required CPU - module version - page size (on Intel platform always 4096 :-) - page shift - object count - resource count - imported entries count - debug info size - start object and EIP - stack object and ESP - module name - module description 1 - OS required to run the executable (always OS/2 :-) - Number of pages present in file - Fixup table overall size - Fixup table overall CRC - Resident portion of header size - Resident portion of header CRC - Automatical data object (valid only for 16-bit executables) - Number of preloaded pages - Additional stack size (has no effect in LX files) - Heap size (extra auto-data-object size; has no effect in LX files) 2 - Uncompressed Page data offset (relative to LX header) - Compressed data offset (relative to LX header) - Page fixup table offset (relative to LX header) - Fixup table offset (relative to LX header) - Imported modules table offset (relative to LX header) - Debug Info data offset (absolute) 3 - Object Table offset (relative to LX header) - Resource Table offset (relative to LX header) - Object Page Map Table offset (relative to LX header) - Module Directives Table offset (relative to LX header) - Non-resident name table offset (relative to LX header) - Non-resident name table size - Imported procedures table offset (relative to LX header) - Entry points table offset (relative to LX header) O Show object info (i.e. information about objects contained in file). Output looks as follows: ## - Base --- Size --R-W-E-Res-Dis-Shr-Pre-Inv-Swp-Rsd-Loc-A16-32B-Cnf-IOP- 1 00010000 00001000 Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y ## Object`s ordinal number Base Object`s base address, i.e. linear address at which it can be placed without applying self-addressing fixups Size Size of the object Further follows object`s flags which describe different attributes of object: - R - Object is readable - W - Object is writable - E - Object is executable - Res - Object is resource - Dis - Object is discardable - Shr - Object is shared among instances (DLLs only) - Pre - Object must be preloaded (this doesn`t work as far as I know) - Inv - Object is invalid - Swp - Object is swappable - Rsd - Object is resident (for ring 0 drivers only, AFAIK) - Loc - Object can be long-term locked (drivers only) - A16 - Alias16, object has an alias in 16:16 format - 32B - Object is 32-bit - Cnf - Object is code-conforming (16-bit drivers only, never seen it) - IOP - I/O priviledge. Object is authorised to access I/O ports. C Object [C]ontents: show pages which makes object. This key enforces /VO. Output looks something like: ++- Index --+ FileOffs + Size + Attribute + + 00000001 + 00012340 + 0123 + LZ-packed + Index Page number in executable (absolute, not relative) FileOffs Offset of page data in file (absolute) Size Size of page data in file Attribute Page attribute: Valid An valid unpacked page RL-packed Compressed using Run-Length encoding (EXEPACK) Invalid Page is invalid Zeroed Page must be zeroed Range ???, no info, never seen one LZ-packed Compressed using Lempel-Ziv encoding (EXEPACK2) R [R]esident Names Table: This is an table which usually contains all exported by name procedures. First entry always contains module name. Display format: + Indx + Name ---------------------------------------------- | 0000 | TCPIPDLL | 0001 | _dn_skipname | 0002 | _res_query | 0003 | _writev [.....................] + 006F + _gethostent Indx This is the index into the Module Entry Table which describes the actual address of routine Name The name of routine as it is imported into other programs. N [N]on-Resident Name Table: This is an table which contains miscelaneous entry points which are not exported. First entry contains module description (if defined). Display format is the same as above. M Imported [M]odule Names Table: This table contains names of all external dynamic-link libraries which uses current module. Display format: + Indx + Offs + Name --------------------------------------- | 0001 | 0000 | SO32DLL | 0002 | 0008 | TCP32DLL | 0003 | 0011 | so32dll | 0004 | 0019 | tcp32dll | 0005 | 0022 | DOSCALLS | 0006 | 002B | NLS | 0007 | 002F | MSG + 0008 + 0033 + setloc1 Indx Index into the module names table; This is often used in fixup records although lxLite resolve such references automatically and shows directly entry name. Offs Offset in the table = sum of lengths of all previous names. This is not used for Module Names Table but is used for Procedure Names Table which is displayed in similar format. Name The name of entry. P Imported [P]rocedure Names Table: This table contains names of all external procedures which are imported by name. Display format is similar to Module Names Table. E Module Entry Table: This is an table which defines some entry points into the current module; not neccessarily all entry points are defined here: only those which are exported MUST be defined here. Here is an sample display: + Indx + Entry Type + Entry Attributes --------------------- | 0005 | 0:32 | 1:00000000, Exported, Shared Data | 000B | 0:32 | 1:00008C90, Exported, Shared Data | 000C | 0:32 | 1:00008FB4, Exported, Shared Data | 002B | 16:16 | 4:02EC, Exported, Shared Data | 002E | 0:32 | 1:00009468, Exported, Shared Data + 0056 + 0:32 + 1:00001448, Exported, Shared Data Indx Index into the entry table. Entry table is always sequential, and all 'holes' between indices are filled with 'unused' entry points (for example, entry point index 10 cannot follow index 5: there must be entries 6,7,8,9 between them marked as 'unused'). lxLite doesn`t show 'unused' entries since this is unuseful; however they are there, just for your information. Entry Type Type of entry point. Entry points can be located in different segments (16-bit, 32-bit, it can be an Call Gate etc), so OS/2 needs a flag which will describe how to handle each entry point. There are also "forwarders" - fake entry points into the module which are in fact redirected into another module. For example, PMWIN.DLL, PMGPI.DLL and many other DLLs are simply a bunch of forwarders which all points to PMMERGE.DLL. Entry Attributes These depends of the entry type. For example, 0:32 entries has Object:Offset32 attribute, 16:16 entries have Object:Offset16 attribute, forwarders have attributes which describe to which module and which procedure to redirect this entry etc. F [F]ixup table. This is useful, I think, only for me and, may be, for those who write compilers :-) Display format: + Object index: 1 Page index: 1 Absolute page: 1 | 32-bit relative offset of import SETLOC1.4 | 045C 0494 04B8 | 32-bit relative offset of import SETLOC1.5 | 035F 0CBA [.....................] + Object index: 1 Page index: 2 Absolute page: 2 | 32-bit relative offset of import SETLOC1.4 | 02B6 0328 0354 090E [.....................] + Object index: 1 Page index: 42 Absolute page: 42 | 32-bit relative offset of import DOSCALLS.256(DosSetFilePtr) | 066F 0C5D 0CD5 | 32-bit relative offset of import DOSCALLS.272(DosSetFileSize) | 0CB2 | 32-bit relative offset of import DOSCALLS.273(DosOpen) | 0B9D [.....................] Imports by ordinals are handled in a special way: lxLite has a resource table which contains information which allows lxLite to transform MODULE:ORDINAL form into an MODULE:NAME pair. By default lxLite contains a list of ordinals for all base OS/2 DLL`s, but if you want to add your own or if you need something special, you can add your module entries to lxLite.rc file in the API subdirectory and then to re-attach resources to lxLite (using Resource Compiler). /W(W|S|+|-) [W]rite (+) or [S]imulate writing of resulting file. In the /WW- state lxLite will do nothing (useful for /V option); in the /WS+ state lxLite will even display compression ratio, but won`t alter the module file on disk. Useful for /V{...} switch, but also can be useful for debugging your options. /X{+|-} e[X]pand (+) or pack (-) given files. Use this switch to decompress files. lxLite can decompress files which has been compressed by itself as well as by other programs which uses standard methods (i.e. Resource Compiler, LINK386, REPACK). It is NOT identical to /c:Unpack option. /Y[U|X|B|C|D]{?} auto-repl[Y] '?' on one of questions: file in [U]se /Answer: [R]eplace, [S]kip, [A]bort/ [D]ebug info in file /Answer: [D]iscard, [L]eave, [S]kip, [A]bort/ e[X]tra data in file /[D]iscard, [L]eave, [S]kip, [A]bort/ [B]ackup file exists /[O]verwrite, [N]o backup, [S]kip, [A]bort/ [C]onfirmation on /P+ /[P]rocess, [S]kip, [A]bort/ If reply (?) is missing, lxLite will ask you interactively each time. When lxLite asks you a question, you can press Alt+letter which will set the default answer for all following similar questions. /Z{:#} This option will set the `threshold` for lxLite to help him determine when stub is a `dummy` one and when it is a functional program. There are a number of programs (for example, \os2\xdfloppy.exe) which runs both under DOS and OS/2 - in such programs DOS executable is implemented into OS/2`s LX as a DOS stub. By default lxLite considers all stubs bigger than 1024 bytes as functional programs, and therefore for such executables the /T{:#} option has no effect. If you want stub to be always replaced, use the /Z option. If you want to disable the /T option, use /Z-1. /?,/H Show a brief help. This is useful when you forget a particular switch from all that list :-) ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Title page | Introduction | Features | Configuration file | Error messages | Bugs and limitations | Thanks... | Utility Pack | Author info ΓòÉΓòÉΓòÉ 1.11. Thanks ΓòÉΓòÉΓòÉ Thanks to: Dmitry Goldobin who digged from OS2LDR information regarding /EXEPACK:2 packing method; the idea about lxLite was born when I was looking this; Rinat Sadretinow who gave me some ideas and informed me about some enhacements in OS/2 v4.0 regarding LX modules; Ilfak Guilfanov who gave me the information about new type of chained fixups in LX modules which appeared in OS/2 v4.0. I also would thank Herwig Bauernfeind who contributed to German translation of the documentation; Alas the link between us is very slow, so German docs are almost always little out of date :-) Sorry, I cannot do nothing with it. Here is a paragraph written completely by Herwig: Translator As I really was very happy about Andys program, I asked whether he would like a German translation of the documentation of version 1.01. Well, some things sound a bit 'bumpy', but first of all, I am doing this as a hobby only, secondly I am not professional programmer. I hope, it will help anyway. You can reach me by email (although this is quite useless, as I contributed the translation only): FIDOnet: Herwig Bauernfeind, 2:312/5.35 InterNet: H_BFD@fidonet.at (does not work reliably by now) ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Title page | Introduction | Features | Command-line switches | Configuration file | Error messages | Bugs and limitations | Utility Pack | Author info ΓòÉΓòÉΓòÉ 1.12. lxLite utility pack ΓòÉΓòÉΓòÉ Abstract Some time after releasing version 1.01 of lxLite (i.e. 1.0.1) (and some time before :-) I wrote some simple command-line utilites which greatly simplified my life. Because apart from lxLite they don`t present nothing interesting, I included them here for you to get them along with lxlite :-) unLock unLock is a simple utility which allows to `unlock` application executables which is currently in use. Normally when an executable is loaded by OS/2 its file is open with a deny-write sharing mode. This is done because LX format structure is designed not to swap out unused pages in executables each time when they aren`t needed anymore, but rather to discard them. When discarded page is needed OS/2 simply reads it again from executable. However, there is still a way to replace executables `on-the-fly` even if they are currently running. There is an so-called `well-known undocumented` function (which in fact means that it won`t be neccesarily supported in future versions of OS/2) which allow to disable sharing protection on such files. Before doing that OS/2 reads entire executable in swap file, then page swapping is done as with usual memory. If you`ll `unlock` many running executables at the same time you can notice an increase in swap file size. So, this is just an temporary work-around, you have better to reboot after doing all neccesary things on former locked files. The command-line format of unLock is much like lxLite`s, except that it have much less options :-) /R{+|-} [R]ecursive (+) file search through subdirectories. unLock will recursively search any directories which is located below the directory of given filemask. If multiple masks are given multiple recursive searchs will be performed. /P{+|-} Enable (+) or disable (-) pause before each file. Before each file unLock will ask you whenever you really want to unlock the file. /V{+|-} Verbose (show additional information). If verbose option is disabled (/V-) only those messages are left on screen which displays critical messages (i.e. errors), otherwise after each filename unLock shows the result of unlock operation - 'unlocked' or 'sharing violation'. Note that unLock CANNOT unlock files which are locked in some other way than executbles. /?,/H Show a short help screen noEA As you probably know :-) many (in fact a lot) of files have EAs (extended attributes), but does not need them. In fact the only thing which REALLY needs extended attributes is your Desktop\ directory. All other files can or can not have extended attributes - the only thing that you can lose by removing those attributes is how that file will appear in WPS folder (size and icon). Other type of extended attributes is those used by REXX - any REXX program that you run at least once and which does not have ReadOnly attribute set have some K of extended attributes attached to it. This is the 'pre-compiled' text of the REXX program, so it will run faster with that attributes. However, if you don`t use the REXX script too often, you can remove extended attributes from file then to set the Read-Only attribute. Note that if you have not too many EAs (say the .TYPE and the .APPTYPE EAs) they will NOT occupy any disk space because of the wise HPFS structure. So to use noEA you MUST know what you`re doing and whenever you needs it (anyway, this is true for any other program :-). noEA can show a list of extended attribute names for the processed files or remove all of them. The command-line switches are much like in all other utilites: /R{+|-} [R]ecursive (+) file search through subdirectories. noEA will recursively search any directories which is located below the directory of given filemask. If multiple masks are given multiple recursive searchs will be performed. /P{+|-} Enable (+) or disable (-) pause before each file. noEA will ask for confirmation before each processed file. /V{+|-} Verbose (show EAs instead of removing them). When this switch is used noEA will display the EAs attached to processed file and will NOT remove them. /Y{+|-} Assume (+) on all queries affirmative responce. When noEA encounters an write-locked file it warns you about this. However, this can be annoying when doing automatical processing (i.e. calling noEA from batch files). You can force noEA to process any files it can by specifying this switch. /?,/H Show a short help screen chCase Some time ago I was finally bored of the annoying habbit of some programs to write their files in upper case. And not only contents (almost any program which changes config.sys tends to convert it all to upper case when I like it to be in lower case) but filenames also. So i started this little project as a problem-dedicated-and-easy-to-use replacement for REN command. The main ideology of chCase is to divide filename in some `parts` then to perform some case-conversions on each part apart :-) You can define `part separator` characters using /S"" option. By default chCase uses "." as `part separator`. I.e. filename chcase.is.a.great.prog will be divided into parts 'chcase', 'is', 'a', 'great' and 'prog'. Further you can tell chCase to convert first part to upper-case, second - to lower-case, third - to mixed format (i.e. first letter in uppercase and rest in lowercase) and so on. The available options are: /C{F|D}(L|U|M|A) Convert to [L]ower/[U]pper/[M]ixed/[A]s-is case. You can define multiple `case conversion actions` - first one will be applied on the first `part`; second - on the second `part` and so on. Last `action` will be used for any extra encountered `parts`, so if you`ll define only one option it will be applyed on all filename parts. Some examples: ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöéfilename Γöécommand line Γöéresulting filename Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ ΓöémY.Very.lOnG.fIlE.NamE Γöé/culam my* ΓöéMY.very.lOnG.File.Name Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöéjust.an.example Γöé/cml jus* ΓöéJust.an.example Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ ΓöéleT.iT.bE Γöé/cmla let* ΓöéLet.it.bE Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ /R{+|-} [R]ecursive (+) file search through subdirectories. chCase will recursively search any directories which are located below the directory of given filemask. If multiple masks are given multiple recursive searchs will be performed. /P{+|-} Enable (+) or disable (-) pause before each file. Before each file chCase will ask you whenever you really want to rename this file. The initial and final filenames are displayed. /S{%} Define separator character(s). You can use this switch in the case when you have some files which uses some other separators, for example space or underscore. Note that the /S switch is NOT additive i.e. any /S switch disables the action of precedent. Even "." is cleared by /S switch, so if you for example want to use as separators both "." and space " " you have to define them both in a single /S switch as follows: /S" ." Just some examples: ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöéfilename Γöécommand line Γöéresulting filename Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ ΓöéMary has a Little.Lamb Γöé/cm /s" ." mar* ΓöéMary Has A Little.Lamb Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöéjohn_wAs_a_lItTle_lame Γöé/cuml /s"_" ΓöéJOHN_Was_a_little_lame Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ /V{+|-} Verbose (show additional information). If you will specify /V- chcase will leave on screen only critical messages such as errors - all others will be cleared immediately after they succeeded. /?,/H Show a short help screen SysIcons This program can change system pointers. It is mainly an GUI interface to WinSetSystemPointer() function, so don`t expect too much :-) Anyway, it has some advanced features such as editing pointers (using OS/2 Icon Editor) and also allows you to choose the method for storing pointers - you can either store into INI file an reference to an external file (so you must not move or delete them) or to store the pointer image directly (so it will occupy space in INI file, but original files on disk can be deleted after this). The interface is quite simple; I`ll describe here only some features that you may not understand. The Icon Filename field displays the full name of pointer file which OS/2 uses at start-up to load currently selected system pointer. If pointer is stored directly into OS2.INI file it will say so. The "Store icon directly/Use file reference" field lets you choose the method which SysIcons will use to store icon reference into INI file. This will work only for those icons which you have changed AFTER setting this button. If "Store icon directly" button is active, you can load icons and then remove them - they will not be used by OS/2 at start-up. The "Change" button displays the standard file dialog and lets you choose another icon instead of highlighted. The "Load Set" button lets you load an entire pointer set instead of loading each file separately. Note that sysIcons use an different from "System Setup->Mouse->Pointers->Load set" method: it uses an plain text file with extension .SET which defines one or more pointer replacements; OS/2`s setup uses hard-coded filenames (i.e. ARROW.PTR will always be the default mouse pointer). The format of .SET file is as follows: ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ; Everything after an semicolon is ignored ; Use semicolons to include comments into .SET file ARROW arrow.ptr ; This statement defines the file ; containing the default mouse pointer TEXT text.ptr ; -//- the text-editing pointer WAIT wait.ptr ; -//- the WAIT mouse pointer SIZE ; Empty lines resets pointer to default value ; The SIZE pointer is valid only in OS/2 v2.x MOVE move.ptr ; This is mouse pointer when moving a window SIZENESW sizenesw.ptr ; arrow from North-East to South-West SIZENWSE sizenwse.ptr ; North-West to South-East SIZEWE sizewe.ptr ; West to East SIZENS sizens.ptr ; North to South APPLICATION applicat.ptr ; Default icon representing an application INFORMATION info.ptr ; The icon displayed in Information messages QUESTION question.ptr ; The icon displayed in Question messages ERROR error.ptr ; The icon displayed in Error messages WARNING warning.ptr ; The icon displayed in Warning messages ILLEGAL illegal.ptr ; The Illegal Action mouse pointer DEFFILE file.ptr ; The default icon representing a file (?) DEFFOLDER folder.ptr ; The default icon representing a folder (?) MULTFILE multfile.ptr ; Multiple-file selection icon (?) DEFPROGRAM program.ptr ; The default icon representing a program ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Along with SysIcons I supplied three sets of system pointers: two of my own design (although some of them I collected from miscelaneous sources) and one of an unknown author (sorry) but that I like most. Hope you like them :-) The "Edit" button stores pointer into a temporary file (if it is not a file reference) and launches Icon Editor. After Icon Editor ends the file is loaded back into INI file. The "Undo" button does what you expect :-) But if you moved the highlight bar after change, you cannot undo the change anymore. The "Default" button does what you expect: it changes pointer to its default shape. The "Quit" button is the coolest feature of my program: hope you like it :-) ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ Title page | Introduction | Features | Command-line switches | Configuration file | Error messages | Bugs and limitations | Thanks... | Author info ΓòÉΓòÉΓòÉ 1.13. whatsnew.txt ΓòÉΓòÉΓòÉ ------------------------- lxLite revision history ------------------------- [;] Comment [*] Modified [+] Added feature [-] Removed feature [!] Bug fix 1.2.1 ----- 17-Aug-97 small bugfix [!] Improved handling of filenames with forward slashes instead of backslashes [!] (yet again :-() changed the 'already packed' detection algorithm. The problem with it is that lxLite does not put any kind of 'fingerprint' into processed files so I have to decide whenever it has been processed or not only by side effects. [*] Made noEA's output a bit quieter. Now without /V option noEA shows all file names in one line and with /V option noEA advances to next line only for those files that has EAs. [!] chCase is back now! I understood why chCase messed up filenames when codepage was 437 :-( Sorry to those who had to reformat their HD to get rid of messy filenames ;-( it is mostly IBM`s fault, not mine. This sometimes breaks HPFS's filename BSP tree and makes files totally unreachable, undeletable etc. 1.2.0 ----- 10-Jul-97 [!!!] Mega-bug fix :-) I caught a very serious error in lxLite. However, I`ve encountered it only on GNU C++ compiler executable when I tried to pack it using RLE (/c:ver2x) method, so it is not too probable that you seen it before :-) The problem was following: for some unknown reason the guys at IBM decided that whenever a packed page is bigger than 0xFFC bytes, it is an error. To understand this, I had to dig through the OS/2 kernel (whew!). So if the compression ratio for some page was really worse (this happens much seldom on EXEPACK2 (LZ) method since it packs better, and often on RLE method since it sucks), the page was simply missing at its memory location (!). In such cases a record is added to POPUPLOG.OS2, looking very unusual (no registers, no location etc). [!] noEA will not bomb out anymore when it tries to process a completely locked file (i.e. ea data. sf). [*] In some situations (very high ordinals in entry table) lxLite began to eat lots of memory, and this usually terminated with an out-of-swap-space trap :-( Fixed. 1.1.9 ----- 10-May-97 Upgrade for version 1.1.8 [*] lxLite is distributed now under GNU General Public License (GPL). [*] lxLite`s documentation is now in both .HTML and .INF format (the .INF book is converted for your convenience with HTML2IPF). [!] Oooooops! I`ve left a debug sequence in fixup packing section, so really fixups were packed ONLY at page N20! :-) [*] Added a little tolerance to minor (and even severe) bugs in fixip table which could lead lxLite to display an 'invalid fixup record' message. [*] More tolerance to incorrect debug information (exceeds executable, encountered on FASTECHO/2 1.46). [!] Yet again improved 'already-packed' modules detection :-) [+] Added the /C{+|-} option for those with a B/W monitors [+] Added the /CS{+|-} option for those who prefer writing to stdout. Actually lxLite isn`t entirely an stdOut program, it still uses VioXXX to do some things, notably get console width and height. You can put this option in the [default] section of config file to force lxLite always write to stdout. [+] Disabled the progress bar indicator when StdOut is redirected. Now you can use lxLite >alternateLogFile without getting much garbage. Try lxLite * | more :-) [!] Captain Nemo`s INI file (NEMO-OS2.INI) has a perfect NE executable structure :-))) so I added NEMO-OS2.INI to the list of excluded files. [+] Added ability to apply (/MFA{+|-}) fixups since some executables (observed on FASTECHO2.EXE - written using Borland C++ for OS/2) were linked without /BASE: linker flag which leads to slower loading times and bigger executables without need since executables are always loaded at 0x10000. This option work only for .EXEs. [*] Now the /V flag works *after* lxLite processes module, so you will see the *final* result of conversion, not the *original* module information. Of course, you can still see the original if you`ll disable all lxLite processing (the /C:info switch will do it for you). 1.1.8 ----- 01-Mar-97; well, its THE time for a new release :-) [!] Fixed a serious bug in run-length packing method: the kernel decompressor expects two zeros at the end of packed data and lxLite didn`t put them there. The bug is since first lxlite release, so if you previously encountered problems (especially using /C:Ver2x switch) you should try to re-pack damaged modules (lxLite will correctly unpack even "incorrect" modules, then will correctly pack them). Big thanks to Vallat Christophe for pointing out this bug. [+] Now to reply to any question you can instead of pressing simply [L]etter press <Alt>+[L]etter which will set the default reply for all following similar questions. [+] Added the /MF3 fixup packing method which will find the best alternative for each page between /MF1 and /MF2. However this is a bit slow and does not give too much gain, so default is still /MF1. [!] Fixed a serious bug in /MF2 packing method. Lucky for you, previous version was not public. [*] Now you cannot proceed module along with displaying module structure (i.e. /V option has priority over any other). 1.1.8g ----- 15-Feb-97, a year from first public release :-) [+] Added some extra gain since now all fixed-up locations are filled with zeros before packing. For modules with pre-applied fixups this operation is not performed. [+] Added fixup packing method for Warp 4.0 (3.0 with fixpack #17) and above (/MF2). This option is still at beta-test stage, so use with care (by default it is disabled now). Anyway, this method has proven to be less effective sometimes than /MF1 with above correction. And note that on most executables this method will have absolutely no effect: it is primarily intended for DLLs. Also note that when fixup packing is enabled, the /U{+|-} option is ignored - module is always unpacked first. The /MF2 option is ignored for modules with pre-applied fixups (for example DOSCALL1.DLL). 1.1.8b ----- 25-Jan-97, my birthday :-) [;] WARNING: This is a PUBLIC BETA version; it still contains bugs, especially in NE->LX conversion routines. USE WITH CARE. I tested it for about a month, and found THREE executables on which lxLite fails to convert (i.e. didn`t convert right from NE format into LX): please avoid them: - OS2DASD.DMD with beta support for HPFS on removable drives (other versions converts OK): halt on reboot with a "Unable to operate your hard drive" message. - RESOURCE.SYS from Warp 4.0 GA: Trap 0D on first keypress after it is loaded. - ES1688.SYS driver for ESS-1688 soundcard; trap when loading. I do not understand why this is happening; everything seems ok, but something is wrong :-( That`s why I`m releasing this public beta version: PLEASE REPORT ME ANY CASES WHEN LXLITE FAILS. Contact information is available at the end of LXLITE.ENG file. [*] Changed configuration file format: now it is Unix-alike, i.e. configuration option is defined using square brakets, for example [default]; next lines are interpreted as command-line options that are loaded when loading specific section. [!] Fixed two bugs in NE fixups conversion routine: this possibly caused most of failures when converting NE modules before. [+] Added exclusions and additional-options-based-on-filemasks needed to entirely compress Watcom C subdirectory without losing functionality of any executable. [*] Added the /NR switch; now lxLite will fail to convert NE files that contains resources; use the /NR option with care, especially on DLLs since you must know what executables uses that DLL and which function (Dos16GetResource or Dos16GetResource2) they`re using to load resources. 1.1.7b ----- internal release [;] Now lxLite converts NE executables into LX. Uhhh! Lots`o`work done. Lots'o'things changed. Lots'o'options added. Some options has been renamed, some merged into one, so read at least following info before trying new version. [*] IMPORTANT: Now all options that can be followed by a string (i.e. file name, configuration ID) must have a semicolon before string, i.e. /C:default, /L:mylog etc. [*] IMPORTANT: I changed a lot of options to make them more mnemonic: The /D option now is called /E ([E]xclude); /E option has been renamed into /R ([R]ecursive); /R option has been added to /A option (which still works in old way (say /APS); you also can directly specify new page shift count i.e. /A:4; you can use them both ways i.e. /APS:4); [*] Changed a lot of internals so it it possible for some bugs to appear. [*] If you choose to load a specific configuration, and configuration file contains more than one line that matches that config ID, lxLite will load all such lines, not only the first as before, so you can split very long configurations into some number of lines. [*] Removed from configuration file options /C:failSafe, /C:fast, /C:fast2 because they`re useless: experience shows that executables packed with /C:default loads and works faster. [!] Increased stack space: small stack space is very like to cause all those strange crashes of lxLite on deep directory trees. [!] Some minor memory leaks has been fixed [+] Added functionality to VERBOSE mode: now you can specify what kind of information you want to see. lxLite can serve as an replacement for EXEMAP and EXEHDR programs :-) More detailed descrition you can find in documentaion (English only, the German docs refers to version 1.1.5). For displaying exported entry points, fixups and forwarders, lxLite now knows a lot of API functions by name. Today lxLite knows by name all documented API functions in all base OS/2 dynamic-link libraries. You can add your own - see the resources in API\ subdirectory. [+] When displaying long texts (i.e. /V{...} option, help text) lxLite will use a kind of 'MORE' prompt. [+] Bundles of entry points now are re-packed although seems that in most cases they are packed well. [+] Fixup records now are also re-packed, although in most cases they are already compressed. If you run lxLite on a previously packed file (with earlier versions) and you get some gain, it means that fixup records (or entry points bundles) has not been packed at the maximum possible level. If you got BIGGER files, please let me know :-) [!] Corrected a bug which leaded to loss of non-resident name table (usually it contains executable description) with a message 'LX file contains extra bytes' when it isn`t. [+] Improved a bit 'already-compressed' executables detection. [+] Added the /J option to change executable type: use it for converted NE drivers since NE drivers are marked as DLLs; LX drivers always must be marked as Device Drivers, otherwise they will not load successfully. [+] Added the ability to use some specific configuration options for filenames that matches specific filemask. For example, if in configuration file you`ll specify the entry: @a*z.c?$: /B this will enable backups for files that matches the "a*z.c?$" filemask, i.e. aaaz.cc$, abcdefgz.ca$ but not for the bcde.cc$. A side effect of this is that you can encounter a option syntax error in the middle of the process, not only at the start. [+] Improved a bit the /L option: now you can choose which types of events you want to log; be careful: now the log filename MUST BE SEPARATED BY A COLON from /L{...}, i.e. /L:"log file" [+] Improved the /B option: now you can choose to backup only in the cases when module contains e[X]tra or [D]ebug data. Also you can choose to place backups in a certain directory; for example with the /B:bak option lxLite will place all backed up files into the \BAK\ directory on the current drive, recreating the same directory structure as the original file was placed in. [*] The /G option has been merged with the /O option; the /G option now is gone. [+] Modified the /W option: in the /WS+ state lxLite will perform just like always, except that it won`t write output file (and will display compression rate too unlike in the /W- state). [*] lxLite utlity pack: version of utilites now will be the same as for lxLite. So all enclosed utilites (chCase, noEA etc) now have version 1.1.7 [*] Options in utilites changed according to changes in lxLite: recursive search changed from /E to /R etc. [+] ChCase: The option /C{...} has been extended: now you can define separate rules for [F]iles and for [D]irectories: The /CF{...} switch will define case conversion rules for [F]iles and /CD{...} switch will define them for [D]irectories. If used in old fashion (i.e. /C{...}) it will work both for files and directories. [!] Both chCase and lxLite when processing a file with no attributes (i.e. attrib -a-h-s-r) will set the Archive flag. [-] Removed ColMng from lxLite utility pack because of its usefulness and excessive complexity for most users :-) [+] Added/changed a whole lot of other things I don`t remember now. 1.1.6 ----- internal release [-] Removed sources from base distribution. The sources are still available on request (see docs for "how to contact" information). This was done since they grow in size very fast (they use some of my external libraries - a function-two from each) and not too much people really needs them. [!] Fixed a bug - the /GX{#} option worked only in /OX+ state [*] Improved a bit help on /O{G|D|X} option [!] Fixed a number of minor bugs in error-correction logic [*] Changed default option in unLock from /V+ to /V- [*] Changed default option in chCase from /V+ to /V- [*] Before unlocking file all utilites saves now file date/time; after unlocking they`re restoring date & time, although this is an overkill (?). 1.1.5 ----- 19-Jun-96 another bug fix :-) [!] AT LAST! The famous `cannot open configuration file` bug fixed :-) The problem was that CMD.EXE puts in environment the command line that you used to start lxLite AS-IS while 4OS2 replaced it by fully-qualified lxLite filename followed by its command-line parameters. I used it to compute lxLite`s source path; however program`s environment contains ANOTHER fully-qualified filename path which I use now :-) and which is ALWAYS fully-qualified. [+] Because nobody understands how the /G switch works (I got a lot of e-mail regarding this) I added a new switch: /O{X|D|S}{+|-}. If it is disabled (/O-, default state) the /G switch works as before, i.e. the data is written only if discarded from source file. If the /O+ option is used, the data is written always (if filemask is specified by /G option). [!] Fixed an non-serious bug in CRT.PAS - now lxLite works as expected even if it is redirected into a device other than CON (i.e. /dev/nul), not only into files or pipes. [+] After a lot of thougts I added into lxLite utility pack my first PM program for OS/2 - SysIcons. It is an simple program which allow you to change system pointers (including but not limiting to mouse pointers, as System Setup->Mouse->Pointer does). Also I included three of my best sets of pointers - one which I partially designed myself, partialy aquired from different sources, second is the B&W version of first and third (white gloves) which I got from somewhere and converted to B&W (because on my Cirrus Logic B&W pointers are supported by hardware and does not flicker). Sorry to the author of White Gloves set, but I lost original archive and copyright notice; I hope you`ll excuse me. [!] Improved a bit error checking; previous versions sometimes (seldom) failed on almost-good-exe-files (specifically GVPM.EXE which had one of non-mandatory internal table beyond the limits of EXE files which caused lxLite to fail with an runtime error). 1.1.4 ----- 14-Jun-96 minor fixes & additions [!] Fixed displaying the question about extra LX data - I forgot to add an carriage return after it. Also I removed the warning about the possibility that resulting file will become non-functional. [!] Fixed a stupid bug (sizeOf(F) instead of fileSize(F)) which sometimes forced lxLite to discard debug info even if you specify to leave it in resulting file. In such cases lxLite displayed that file has X bytes of extra data and the same amount of debug info. [+] Added an sub-option for /G[X|D|S]{#} - the /GX option now specifies the filemask for files where to store stubs (even if lxlite won`t remove them). [!] Fixed a minor bug in lxLite - when file was already processed but stored with debug info and you process it again and choose to discard debug info it refused to do it because `file was already processed`. [!] Fixed a serious bug - the /G option in version 1.1.3 DOES NOT DO WHAT YOU PRESUME :-) It stored garbage instead of debug/extra data. [*] The option /GX*.$x$ is used by default. This was done for those executables which failed to run after packing because the extra data has been stripped. Use COPY /B {file}.exe+{file}.x {newfile}.exe command to append extra LX data back - in most cases this will restore the functionality of LX files. Note that now lxLite leaves those *.$x$ files as garbage, so don`t forget to test the executable functionality and to delete them if executable still works. [*] Improved performance of ChCase - now when computed filename will be the same as initial file will be simply skipped. 1.1.3 ----- 28-May-96 fixes & changes [*] Modified lxLite to redraw its progress bar only when it really changes. This may improve its execution speed when running it in windowed sessions (however I don`t use them :-) [+] Added option /G[X|D] which specifies an file mask for files where to store the e[X]tra LX data and [D]ebug info when encountered and if user chooses to discard it. [+] The /S switch now displays the status of the /I switch also. This is done for those who don`t believe that it always works (you know who you are :-) [-] Removed the /O{#} option which has proven to be useless. [-] Removed the old /D{+|-} switch (debug info remove on/off). Now lxLite prompts the user if the debug info is encountered; however the default behavior is to discard debug info (/YDD) as before. Now /D switch have other meaning (see below). [+] Added (other) /D switch to set exclusion filemasks. Filemasks uses the same rule as OS/2 does (in fact, lxLite uses OS/2 API to do that). For example, /Dex*re.??e:*.zip:*.pas:*.obj will exclude these files from lxLite`s field of view. The default configuration now includes the [exclude] configuration which excludes all known executables on which packing cannot be performed (such as PMJPEG, Watcom C etc). Masks should be separated by ':'; the ',' and ';' symbols can be present in HPFS long filenames, so they aren`t taken into account. [+] The /Y switch is modified (expanded). Now you can specify answers for each type of possible questions separately. The /Y switch must be followed by a letter - ID of answered question, then a letter - what do you want answer to be to that question. The possible IDs for now are: ----------------------------------------------------------------------- Module is in [U]se (answers: [R]eplace, [S]kip or [A]bort); File contains [D]ebug info ([D]iscard, [L]eave, [S]kip or [A]bort); File contains e[X]tra data ([D]iscard, [L]eave, [S]kip or [A]bort); .[B]AK file already exists ([O]verwrite, [N]o backup, [S]kip or [A]bort); Confirmation (/P+) ([P]rocess, [S]kip or [A]bort); ----------------------------------------------------------------------- For example, the /YUR switch will instruct lxLite always to replace modules which are in use. The defaults are: /YBN /YDD and /YXD. [+] Added /L{#} switch to specify an [L]og file name. If no filename is specified, the log file will be created as lxLite.log in the same directory as lxLite.exe. The log file contains a list of processed files, their initial and final sizes, and also all problems (if any) which have been encountered when processing the file. 1.1.2 ----- 22-May-96 minor additions and changes [;] The BOXER for OS/2 APAR is closed now :-) At last I downloaded it from hobbes and it works packed absolutely without any problems. This is due to the effect of `overlayed data` for which support has been added in version 1.1.1. [+] Added an alternative [D]iscard choice when prompting for an action when data out of LX structure is detected. Some DLL`s (even from \OS2\DLL) seems to contain some garbage after end of LX file. [*] Changed memory allocation strategy - now memory manager allocate memory in 64K chunks which can fix the problem of slow performance on low-memory machines (8mb and less) when processing large files (i.e. TUTORMRI.DLL). I can`t check this - please mail me if it works. [*] Changed backup strategy - now lxLite always make .BAK file even if backups are disabled (/B-). If operation succeeds and backups are disabled it is then removed. No more `$lxlite$.tmp` file. [*] Now lxLite says '(very!)' in phrase 'It is (very!) possible that resulting file will be non-functional' only if the size of data out of LX structure is bigger than 256 bytes (this can be changed by /O{#} option /see below/). If overlay size is bigger and /Y+ switch is specified file is skipped otherwise overlayed data is [D]iscarded. [+] Added /O{#} option which allows to specify threshold size for overlay data. All overlays less than this value are discarded with /Y+ switch. For more information please refer to english documentation. [*] Modified defaults - now lxLite by default doesn`t pack using run-length method AT ALL (i.e. as if you specified /MRN switch). That is because I hadn`t found even a case when using this method lxLite produced packed files by at least A BYTE less in size. Instead it compresses now A LOT faster. 1.1.1 ----- 07-May-96 bugfix [!] noEA and chCase v1.0.0 does not work on directories - they says that the module is in use. Version 1.0.1 is fixed. [!] lxLite, noEA, unLock and chCase leaves sometimes garbage on screen especially when processing long subdirectories. Fixed. 1.1.0 ----- 06-May-96 some additions + minor bugfix [*] Change in version numeration: Now version numbers conforms to GNU standards. The first is major release number; second is minor release ordinal and third is incremented only on bug-fixes. [!] Now lxLite checks for a valid MZ header in DOS executable stub. [!] Fixed: lxLite stops sometimes after trying to `pack` locked files (i.e. swapper.dat) with a runtime error. The cause was a bug (sic!) in DosEnumAttribute - when you issue it on a locked file it trashes memory AFTER buffer passed to it (in my cause this trashed the stack). [+] Now lxLite understands quoted long complex filenames on the command line like most OS/2 commands do. I.e. you can write lxLite "my own subdirectory\my executable file.exe" /cmax [+] Added option /Q - query list of configurations. [+] Added option /I{+|-} - Run/don`t run at idle priority [+] Added detection of `overlayed` executables (usually from Watcom) - for more information see English documentation. [+] Added `lxLite utility pack` which now consists of: - unLock which allow to unlock `locked` executables - chCase which allow to automatically change case of individual filenames as well as of groups of filenames - colMng is a simple utility to manage your WPS color palettes - noEA which allow to remove extended attributes from files and directories 1.01 ---- 23-Feb-96 minor bugfix [!] Bugfix :-) in v1.00 docs I erroneously stated that Alice was born at 13-Feb-96; however the real date is 12-Feb-1996 :-) [!] Now lxLite preserves not only timestamp but also file attributes. The version 1.00 erroneously stated that file is used by another process in the case lxLite failed to access it because of read-only or system attribute. [!] Fixed: lxLite preserves now extended attributes of the file. Sometimes EAs are useful, although mostly occupies disk space :-) [!] Fixed: lxLite now COPIES file into/from backup copies instead of renaming them: this caused the WorkPlace Shell to track such operations and to change the `program filename` field in program object. [*] Now /R{#} option can be used to re-align pages even on 1 (byte) boundary. This will get some extra bytes, however LINK386 does not allow this value to be less than 4 (but OS/2 eats it) - use at your own risk. [-] Removed `Switch-to-foreground-when-asking` feature. This was implemented rather as a lab work than a useful feature :-) On the other hand, the version with this feature must use PMSHAPI.DLL which is not always available (in particular when booting from OS/2 repair/installation diskettes). 1.00 ---- 15-Feb-96 first release version [!] When an invalid page is encountered don`t exit with an error but check first if this page is used. (Encountered on npswpsri.dll 1.81). This is an invalid executable; however error is not fatal because page isn`t used and OS/2 loads that DLL without problems. [!] Now lxLite keeps and restores original executable timestamp. [!] Fixed an error when OS/2 locks up on some DOS executables because it contained a 0 at offset 3Ch in DOS EXE header. [*] Changed format of .CFG file. Now it is a plain ASCII text file. For details refer to documentation, section about options. [-] Removed /D# option - use a text editor to add new cfgs. [+] Added /D{+|-} option allowing to remove debug information. [+] Added ability to recognize files packed with ABSOLUTELY THE SAME options, so lxLite will not proceed the same file twice. "The same" means that files will be recognized as packed ONLY if it has been processed with the same switch(-es) which influence resulting file size. Use /F+ (see below) switch to bypass this detection if you want to process file anyway - for example if it has been already packed, but not so good as it can be, i.e. by LINK386 or REPACK. [+] Added /F{+|-} option allowing to force repacking even if lxLite thinks that it is not needed. Use to bypass autodetection (`already processed' message). [+] Added /T{#} option allowing to replace DOS stubs. Use /T alone to completely remove DOS stubs - useful for DLLs `cause they cannot be run from DOS session at all. [+] Added ability to replace even USED! i.e. `active` .DLL`s and executables. Now you can repack entire \os2\*\*.* subdirectory without having to do a clean boot. Note that you better reboot after such operations because OS/2 will throw away all its internal cache buffers for this module and it (i.e. its old copy) will be kept entirely in memory/swapfile. [+] Now lxLite runs at the idle:16 priority so it won`t overload your CPU. [+] Now when lxLite encounters a problem to which he needs your answer he brings itself to the foreground. The only thing to say about it is: because of that lxLite uses now PMSHAPI & PMWIN.DLL, so it most likely will not run under T-Shell. Because of that there are TWO supplied versions of lxLite: lxLite-T.exe and lxLite.exe. Delete first if you will not need lxLite with a clean boot. [+] Added /Z{#} option which defines the threshold for lxLite to separate programs with `functional` stubs such as dual-mode executables from 'dummy' stubs. Default size is 1024 bytes, i.e. on all executables with stub size bigger than 1024 bytes the /T{#} option will have no effect. 0.99b ----- 07-Feb-96 beta-test version [;] What`s new? Nice question :-) ΓòÉΓòÉΓòÉ 2. External links ΓòÉΓòÉΓòÉ This chapter contains all external links referenced in this book - either link is an Unified Resource Locator (URL) or simply to a local file which is not a part of this book. ΓòÉΓòÉΓòÉ 2.1. http://hobbes.nmsu.edu ΓòÉΓòÉΓòÉ The link you selected points to an external resource. Click the URL below to launch IBM Web Explorer http://hobbes.nmsu.edu ΓòÉΓòÉΓòÉ 2.2. http://www.anybrowser.org/campaign/ ΓòÉΓòÉΓòÉ The link you selected points to an external resource. Click the URL below to launch IBM Web Explorer http://www.anybrowser.org/campaign/ ΓòÉΓòÉΓòÉ 2.3. mailto:bit@freya.etu.ru ΓòÉΓòÉΓòÉ The link you selected points to an external resource. Click the URL below to launch IBM Web Explorer mailto:bit@freya.etu.ru